|
|
| Line 5: |
Line 5: |
| | Notes after the report was finished: | | Notes after the report was finished: |
| | * [https://forge.switch.ch/redmine/projects/sts/wiki/Wiki EMI STS] is a new contender, but uses SAML ECP, which not many IdPs support | | * [https://forge.switch.ch/redmine/projects/sts/wiki/Wiki EMI STS] is a new contender, but uses SAML ECP, which not many IdPs support |
| − |
| |
| − | <br />
| |
| − |
| |
| − | == General requirements ==
| |
| − | The general delegation issue as [http://agenda.nikhef.nl/conferenceDisplay.py?confId=993 discussed before] has the following 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) (*)
| |
| − | * Easy to create (by researchers)
| |
| − | |
| |
| − | ''for the '''System''' as a whole''
| |
| − |
| |
| − | * 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:
| |
| − | * Restrictions on delegation
| |
| − | * Performance / overhead
| |
| − |
| |
| − | (*) ''"Workshop security for web services - discussion minutes"'', W. van Engen, 2010
| |
| − |
| |
| − | == Specific requirements for this use-case ==
| |
| − | The practical use-case that is being looked at is a lot simpler. Here a user logged into the [http://www.clarin.eu/cmdi CMDI] portal needs to be able to access private information in the [http://www.isocat.org/ ISOcat] registry. This means that logging into the CMDI portal should give access to the ISOcat registry as well. How exactly, that is the topic of this discussion.
| |
| − |
| |
| − | The requirements for this specific use-case are equal to the general case though a little simpler:
| |
| − | # Only one level of delegation is required: a single service should be accessed from the portal
| |
| − | # All user interaction is in the web-browser
| |
| − | # Delegation needs to happen only when the user is active in the portal (not offline)
| |
| − |
| |
| − |
| |
| − | == 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 requiring a user to be logged in. This could be manageable when administered by a single person. Adding a service requires some some degree of proof that it behaves well.
| |
| − |
| |
| − | <div style="clear:right"></div>[[Image:Approaches_shibboleth_delegation.png|150px|right|Shibboleth diagram]]
| |
| − |
| |
| − | === SAML ECP ===
| |
| − | There is a SAML [http://wiki.oasis-open.org/security/SAML2EnhancedClientProfile Enhanced Client or Proxy (ECP) profile] that supports delegation of credentials. Delegation is done directly by the identity provider, which requires support. Since people of all (European) federations need to be able to use the system, this is probably not possible.
| |
| − |
| |
| − | It also [https://spaces.internet2.edu/display/ShibuPortal/Configuring+Shibboleth+Delegation+for+a+Portal#ConfiguringShibbolethDelegationforaPortal-What%27sgoingon appears to be required] that each IdP should be configured which services can delegate to which other services. This requires too much interaction with IdP maintainers.
| |
| − |
| |
| − | ==== Shibboleth ====
| |
| − | [http://shibboleth.internet2.edu/ Shibboleth] is used by many IdPs. It has [https://wiki.shibboleth.net/confluence/display/SHIB2/ECP#ECP-Directvs.DelegatedAuthentication ECP] support with [https://spaces.internet2.edu/display/ShibuPortal/Configuring+Shibboleth+Delegation+for+a+Portal delegation]; Shibboleth v1.2.3+ has a plugin for this, while Shibboleth v2.2+ has this included by default. Services using this can rely on the corresponding [https://wiki.jasig.org/display/UPM31/Delegated+Authentication+Integration+Library delegated authentication integration library].
| |
| − |
| |
| − | If all IdPs would have Shibboleth version v2.2 or higher this could be a very interesting option. Most of the IdPs [https://refeds.terena.org/index.php/FederationProtocol appear to use] Shibboleth 2.x and/or
| |
| − | [http://simplesamlphp.org/ SimpleSAMLphp] (which doesn't [http://markmail.org/message/54pbhpzqwr6dlzd5 seem] to support ECP), though some use [http://www.pingidentity.com/our-solutions/pingfederate.cfm PingFederate], [http://papi.rediris.es/ PAPI], OpenAthens or possibly [https://refeds.terena.org/index.php/ProductInteroperability other products].
| |
| − |
| |
| − | <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. The service manages its own access tokens, each service needs an access token that originates from the user's browser (obtained via redirection). So nested service invocations are not an option. This would suffice for this specific use-case, but not in general.
| |
| − |
| |
| − | <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>
| |
| − | === WS-Trust / SAML STS ===
| |
| − | It is also possible to use SAML with an STS. This is probably much like the OAuth 2.0 scenario. More research pending...
| |
| − | SURFnet has had an evaluation of this with respect to delegation. [http://www.surfnet.nl/Documents/indi-2009-06-012%20(SURFnet%20Webservices%20en_SURFfederatie)-5.pdf 1] [http://www.surfnet.nl/Documents/indi-2009-10-014%20(SURFnet%20PoC%20Webservices%20en_SURFfederatie).pdf 2]
| |
| − |
| |
| − | Probably WS-Security is only supported with Shibboleth 2 and higher (not 1.x).
| |
| − |
| |
| − | <div style="clear:right"></div>[[Image:Approaches_sts.png|150px|right|STS diagram]]
| |
| − |
| |
| − | === Intermediate Token Portal ===
| |
| − | Expanding 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|Browser mashup 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.
| |
| − |
| |
| − | In web terminology this is called [http://en.wikipedia.org/wiki/Same_origin_policy cross-domain] transport/communication, which could be implemented using an <tt>iframe</tt>, 3rd-party cookies, JSONP, referer and probably others. [http://grack.com/blog/2010/01/04/more-on-window-name-cross-domain-transports/ 1] [http://www.sitepen.com/blog/2008/07/30/protected-cross-domain-authentication-with-javascript/ 2]
| |
| − |
| |
| − | This is not a general solution, but may be a simple solution for this specific case.
| |
| − |
| |
| − | <div style="clear:right"></div>
| |
| − | === Moonshot ===
| |
| − | The [http://www.project-moonshot.org/ Moonshot project] is focused on also making non-web-browser-clients work with federations. A token is obtained from an identity provider (using PEAP) which is used to access the service. In this GEANT3 project there are also ideas to implement single sign-on and delegation based on Kerberos.
| |
| − |
| |
| − | This requires support at the client-side, which means the user's web browser. For Firefox there is an extension, for other browsers I haven't been able to find something. This probably means that the project is in a too early stage to make use of; not necessarily its technology but field adoption.
| |
| − |
| |
| − | <div style="clear:right"></div>
| |
| | | | |
| | == Links == | | == Links == |
