Difference between revisions of "CLARIN/OAuth2"

From PDP/Grid Wiki
Jump to navigationJump to search
Line 26: Line 26:
  
 
* [http://www.rediris.es/oauth2/ OAuth2lib]: client does SAML SSO login. By presenting the returned attributes to the AS, it obtains an access token for the RS.
 
* [http://www.rediris.es/oauth2/ OAuth2lib]: client does SAML SSO login. By presenting the returned attributes to the AS, it obtains an access token for the RS.
** uses Simple Web Tokens
+
** uses Simple Web Tokens (SWT)
 
** ''':)''' AS trusts RS; signed access token by shared secret
 
** ''':)''' AS trusts RS; signed access token by shared secret
 
** ''':((''' AS fully trusts client to supply user attributes
 
** ''':((''' AS fully trusts client to supply user attributes
Line 39: Line 39:
 
**** ''':)''' allows to use generic OAuth2 clients (no SAML support required)
 
**** ''':)''' allows to use generic OAuth2 clients (no SAML support required)
 
**** ''':(''' requires development of new service endpoint
 
**** ''':(''' requires development of new service endpoint
 +
* [https://cwiki.apache.org/confluence/display/AMBER Apache Amber] full suite
 +
** ''':(''' found no SAML-support (yet?)
 +
** ''':(''' trouble building the thing when I tried
 +
* [http://rack-oauth2-provider.heroku.com/ rack-oauth2-provider] converts a SAML assertion to a signed SWT token
 +
** might be an option for the authorization endpoint mentioned above?

Revision as of 11:43, 10 November 2011

Documents

Software

AS=Authentication Server, RS=Resource Server

Use-case

A user accesses a web portal ("client" in OAuth2 terminology) for editing data. He logs in using SAML SSO. Somewhere in the process, the portal needs to access the user's data on service B. Using the existing SAML SSO login, the portal accesses service B without having to ask the user's confirmation again. Access to service B can be implemented using OAuth 2.0. There are several ways to do this. Let's see what existing implementations provide.

  • OAuth2lib: client does SAML SSO login. By presenting the returned attributes to the AS, it obtains an access token for the RS.
    • uses Simple Web Tokens (SWT)
    • :) AS trusts RS; signed access token by shared secret
    • :(( AS fully trusts client to supply user attributes
      • Either client could pass signed SAML statement from IdP to AS, which then can verify that.
        • related to draft-ietf-oauth-saml2-bearer (and expired draft-campbell-oauth-saml); AS would need to check that it was signed to the portal's SAML SP endpoint according to draft :/
        • :( would require signatures of all IdPs at each AS (in addition to clients); can be done using eduGAIN
        • :( requires patching of OAuth2lib (and maybe SimpleSAMLphp too)
      • Or introduce an authorization endpoint that does SAML SSO login for the client
        • :) returns user attributes token to client
        • :) signed token so AS can check it was supplied by the authorization endpoint (shared secret)
        • :) client does not need to know about SAML SSO
        • :) allows to use generic OAuth2 clients (no SAML support required)
        • :( requires development of new service endpoint
  • Apache Amber full suite
    • :( found no SAML-support (yet?)
    • :( trouble building the thing when I tried
  • rack-oauth2-provider converts a SAML assertion to a signed SWT token
    • might be an option for the authorization endpoint mentioned above?