Difference between revisions of "CLARIN/Security for web services"

From PDP/Grid Wiki
Jump to navigationJump to search
(add shibboleth image)
(more clarity in lay-out)
 
(57 intermediate revisions by 2 users not shown)
Line 1: Line 1:
* [http://www.isocat.org/ ISOcat] registry
+
{{CLARIN}}
* [http://www.clarin.eu/cmdi CMDI], component metadata infrastructure
+
'''This page has been superseded by a [[Media:Clarin-security_for_web_services-research-report010.pdf|report]].''' <br />
 +
A conclusion was to look into [[CLARIN/OAuth2|OAuth2]], which is being looked at [[CLARIN/OAuth2|here]].
  
== Requirements ==
+
----
{|
 
|- valign="top"
 
|
 
''for the '''User''' ''
 
* Single sign-on (*)
 
* Access public and private resources from within portal (and web services)
 
* Transparent, no required confirmation for every service or service access (*)
 
|
 
''for '''Services''' ''
 
* Authentication by identity provider (IdP)
 
* Authorization by service owner (*)
 
* Nested service invocation possible (delegation of the user's credentials) (*)
 
|
 
''for the '''System''' as a whole''
 
* Multi-federation authorization, with Shibboleth/SimpleSAMLphp (*) [http://www.clarin.eu/files/trust_domain-CLARIN-ShortGuide.pdf #] [http://www.clarin.eu/files/wg2-6-requirements-doc-v2.pdf §5.1.5]
 
* SOAP and(/or) REST (*) [http://www.clarin.eu/system/files/SOA-CLARIN-ShortGuide.pdf #]
 
* Using proven technologies
 
* Operational effort minimal (*)
 
* In-line with standards & best practices [http://www.clarin.eu/files/standards-CLARIN-ShortGuide.pdf #]
 
* Can we start today? (*)
 
|}
 
  
Optional or variable criteria:
+
Notes after the report was finished:
* Restrictions on delegation
+
* [https://forge.switch.ch/redmine/projects/sts/wiki/Wiki EMI STS] is a new contender, but uses SAML ECP, which not many IdPs support
* Performance / overhead
 
 
 
(*) ''"Workshop security for web services - discussion minutes"'', W. van Engen, 2010
 
 
 
== Options ==
 
There are different ways of tackling the issue, but only some can survive. ''(In the diagrams solid lines are browser redirects, dashed lines are communication outside of the browser.)''
 
 
 
<div style="clear:right"></div>[[Image:Approaches_open.png|150px|right|Open diagram]]
 
=== Open ===
 
All services trust each other. No technical security measures (other than, possibly, blocking complete strangers); managable upto ~15 services [TODO ref needed]
 
 
 
<div style="clear:right"></div>[[Image:Approaches_shibboleth_delegation.png|150px|right|Open diagram]]
 
=== Shibboleth + delegation ===
 
[http://shibboleth.internet2.edu/ Shibboleth] is already used for federated authentication. It has [https://spaces.internet2.edu/display/SHIB2/ECP#ECP-Directvs.DelegatedAuthentication ECP] support with [https://spaces.internet2.edu/display/ShibuPortal/Configuring+Shibboleth+Delegation+for+a+Portal delegation], though only through a plugin. The next major IdP release [https://spaces.internet2.edu/display/SHIB2/ECP#ECP-CodeAvailability may] include it though.
 
 
 
One cannot expect each IdP to install this plugin, or to have the latest version installed [TODO check if this is the case with Shibboleth version policies]. Therefore this option is not viable.
 
 
 
=== SAML ECP ===
 
(see Shibboleth) [TODO would there be other SAML ECP options than Shibboleth?]
 
 
 
<div style="clear:right"></div>[[Image:Approaches_oauth1.png|150px|right|OAuth 1.0 diagram]]
 
=== OAuth 1.0 ===
 
[http://tools.ietf.org/html/rfc5849 OAuth 1] is used on the world wide web as a method to access server resources on behalf of a resource owner. It is used by [http://wiki.oauth.net/w/page/12238516/FrontPage quite] a number of big websites like [http://code.google.com/apis/accounts/docs/OAuth.html Google], [http://dev.twitter.com/pages/sign_in_with_twitter Twitter].
 
 
 
OAuth 1.0 requires browser redirection and confirmation [TODO check if confirmation is optional]. This might be acceptable for the portal scenario, but not for nested service invocations (real delegation).
 
 
 
 
 
<div style="clear:right"></div>[[Image:Approaches_oauth2.png|150px|right|OAuth 2.0 diagram]]
 
=== OAuth 2.0 ===
 
[http://oauth.net/2/ OAuth 2] is the next evolution of OAuth (still in draft), which supports many more scenario's. This is being adopted ([http://developers.facebook.com/docs/authentication/ Facebook] is on the wagon already). RedIRIS has already made this work with Shibboleth in [http://www.rediris.es/oauth2/ OAuth2lib]. Here the AS is a token service that is populated by the portal.
 
 
 
<div style="clear:right"></div>[[Image:Approaches_sts.png|150px|right|OAuth 2.0 diagram]]
 
=== Intermediate Token Portal ===
 
Expading on the OAuth 2.0 approach, one could decouple feeding the token service (STS, or AS in previous diagram) from the user portal: a dedicated portal (that is invisible to the user by redirects) could do this instead. This could improve security and make building portals easier.
 
 
 
<div style="clear:right"></div>[[Image:Approaches_separate.png|150px|right|OAuth 2.0 diagram]]
 
=== Browser mashup ===
 
It may also be possible to keep the portal and service completely separated and combine them in the browser (the web mashup approach). As the service is in this case no more than a pick-list, it could be put in an iframe, which could somehow return a value to the parent document (some tricks required, but it may be possible). Authentication of the portal and the service is then completely unrelated, but single sign-on can make this a smooth experience.
 
 
 
This is not a general solution, but may be a simple solution for this specific case.
 
 
 
<div style="clear:right"></div>
 
  
 
== Links ==
 
== Links ==
 
=== Standards ===
 
=== Standards ===
* [http://kantarainitiative.org/confluence/display/uma/UMA+Explained User Managed Access] (UMA) has some overlap with this work
+
* [http://kantarainitiative.org/confluence/display/uma/UMA+Explained User Managed Access] (UMA) has some overlap with this work; [http://www.ietf.org/mail-archive/web/oauth/current/msg08556.html seems to be] useful for person-to-person sharing
 
* [http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss OASIS Web Services Security]: [http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-SOAPMessageSecurity.pdf WS-Security], [http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf username], [http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-x509TokenProfile.pdf X.509], [http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-SAMLTokenProfile.pdf SAML]
 
* [http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss OASIS Web Services Security]: [http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-SOAPMessageSecurity.pdf WS-Security], [http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf username], [http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-x509TokenProfile.pdf X.509], [http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-SAMLTokenProfile.pdf SAML]
 
* [https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml/ A SASL and GSS-API Mechanism for SAML], uses base64 encoded SAML request in URL
 
* [https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml/ A SASL and GSS-API Mechanism for SAML], uses base64 encoded SAML request in URL
 +
* [http://download.oracle.com/docs/cd/E17802_01/webservices/webservices/reference/tutorials/wsit/doc/WSIT_Security4.html ways to use SAML] (and [http://download.oracle.com/docs/cd/E17802_01/webservices/webservices/docs/1.6/tutorial/doc/XWS-SecuritySamples7.html#wp580431 SAML interop scenarios])
 
* [http://tools.ietf.org/html/draft-ietf-oauth-v2-10 OAuth 2.0], and [http://iiw.idcommons.net/SAML_Profiles_for_OAuth with SAML assertions]
 
* [http://tools.ietf.org/html/draft-ietf-oauth-v2-10 OAuth 2.0], and [http://iiw.idcommons.net/SAML_Profiles_for_OAuth with SAML assertions]
  
 
=== Libraries ===
 
=== Libraries ===
 
* [http://www.rediris.es/oauth2/ OAuth 2 assertion profile library]
 
* [http://www.rediris.es/oauth2/ OAuth 2 assertion profile library]
* Shibboleth [https://spaces.internet2.edu/display/SHIB2/ECP#ECP-Directvs.DelegatedAuthentication ECP] [https://spaces.internet2.edu/display/ShibuPortal/IdPDelegationExtension delegation], [https://forge.switch.ch/redmine/projects/idwsfecp/wiki web-service client], and [https://spaces.internet2.edu/display/ShibuPortal/Configuring+Shibboleth+Delegation+for+a+Portal configuring it].
+
* Shibboleth [https://wiki.shibboleth.net/confluence/display/SHIB2/ECP ECP] [https://spaces.internet2.edu/display/ShibuPortal/IdPDelegationExtension IdPdelegation], [https://forge.switch.ch/redmine/projects/idwsfecp/wiki web-service client], and [https://spaces.internet2.edu/display/ShibuPortal/Configuring+Shibboleth+Delegation+for+a+Portal configuring it].
  
 
=== Federations ===
 
=== Federations ===
 
* [http://www.geant.net/Services/EndUserApplicationServices/Pages/eduGAIN.aspx eduGAIN]
 
* [http://www.geant.net/Services/EndUserApplicationServices/Pages/eduGAIN.aspx eduGAIN]
 
* [http://code.google.com/apis/opensocial/ OpenSocial]
 
* [http://code.google.com/apis/opensocial/ OpenSocial]
* [http://www.surfnet.nl/nl/Thema/SURFfederatie/diensten/Pages/ SURFfederatie diensten]
+
* [http://www.surfnet.nl/nl/Thema/SURFfederatie/diensten/ SURFfederatie diensten]
  
 
=== Other ===
 
=== Other ===
 
* [http://saml.xml.org/forum/n-tier-usage-of-saml-in-the-backend N-tier usage of SAML in backend]
 
* [http://saml.xml.org/forum/n-tier-usage-of-saml-in-the-backend N-tier usage of SAML in backend]
 +
* [http://www.omg.org/news/meetings/workshops/Web_Services_USA_Manual/02-3_K_Smith.pdf Similar project] in US' department of defense
 +
* [http://portabilitypolicy.org/ Data portability], and [http://dataportability.org/ blog]
 +
* OAuth 2 uses bearer tokens and misses signatures, which [http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/ may become a problem].
 +
* Nice [http://davidlyness.com/post/twitter-oauth OAuth 1] and [http://www.independentid.com/2011/03/oauth-flows-extended.html OAuth 2] diagrams
 +
* [http://profsandhu.com/zhang/pub/sacmat11-xdauth.pdf xDAuth]
 +
* [http://contentdm.lib.byu.edu/ETD/image/etd2515.pdf SimpleAuth]: adaptation of OpenID to support delegation (though this might be something entirely different)
 +
* [http://ndg-security.ceda.ac.uk/wiki/MashMyData MashMyData security model]

Latest revision as of 11:28, 26 February 2013

<sidebar>

</sidebar> This page has been superseded by a report.
A conclusion was to look into OAuth2, which is being looked at here.


Notes after the report was finished:

  • EMI STS is a new contender, but uses SAML ECP, which not many IdPs support

Links

Standards

Libraries

Federations

Other