CLARIN/OAuth2

From PDP/Grid Wiki
Jump to navigationJump to search

<sidebar>

</sidebar> The european project CLARIN aims to provide an e-science infrastructure for language research. An important issue is that access to corpora or webservices is often restricted. To give researchers the possibility to perform operations on these corpora using web services, it is necessary that the user delegates credentials to these web services.

After a workshop to discuss general approaches, more detailed requirements were gathered, and a number of technologies was assessed (report and some notes). Conclusion was to look into OAuth 2.0, with certificates as an alternative if that fails. This page discusses the OAuth 2.0 approach to delegation and web services; it is a work-in-progress notes page. Now and then the status report is updated with more structured and readable information.

Discussion takes place at the mailing-list csne-security-discuss (used to be the biggrid-clarin-security-discuss).

See also this use case and the corresponding report.

NOTE: the remainder of this page needs updating, due to the rapid changes in the OAuth2.0 landscape.

Activities and collaborations

Delegation for web services is getting atttention! Let's share and work together on a sustainable and interoperable solution in the end.

Related topics, groups and people

Groups with people that may be / are interested in delegation for web services.

  • DARIAH is a related project for the arts and humanities; they are looking into OAuth 2 for web service delegation as well; see here for more groups
  • Federated Identity Management (FIM) group is focusing on authentication (paper)
  • EUDAT has an AAI part
  • Shibboleth/Internet2 is about SAML SSO, and also includes users who want similar things
  • Contrail is using OAuth2 to provide short-lived (proxy) certificates for a similar use-case, explained here.

Other options

There are still other options that we may look at, even if for comparison.

  • EMI STS - requires SAML ECP, which is not expected to be widespread in the short term
  • GEMBus STS

Documents

Software

AS=Authorization Server, RS=Resource Server

Commercial offerings

Options for the 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.

The access to service B can be implemented using OAuth 2.0. In this case it is a three-legged OAuth 2 flow, with three different endpoints: authorization endpoint doing user authentication, token endpoint handing out the access token (AS), and the resource endpoint providing the service to the client or user (RS).

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.
    • demo; select default-sp for Feide's OpenIdp or default-sp-userpass and login with demo/demo
    • uses Simple Web Tokens (SWT)
    • :) AS trusts RS; signed access token by shared secret
    • :(( AS fully trusts client to supply user attributes; possible solutions:
      • 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 client (and maybe SimpleSAMLphp too; mod_shib would work) to send signed SAML
        • :( requires patching of OAuth2lib AS to verify SAML (possibly with help of SimpleSAMLphp)
        • the IdP can be seen as a non-standard authorization endpoint
      • Or introduce an authorization endpoint that does SAML SSO login for the client
        • could return user attributes token to client (besides to the AS)
        • :) 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 (can switch authentication methods by adapting authorization endpoint only)
        • :( requires development of new service endpoint
        • :( requires patching of OAuth2lib AS to accept SWT from client
  • 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?
  • oauth2-php server+client
    • not ready-to-go, but looks like it could be an alternative library to build upon
    • was able to create a client interfacing with Github
  • python-oauth2 server+client library
    • not ready-to-go, also something to build upon
  • rack-oauth2 server+client
    • nice library, not ready-to-go, something to build upon

Conclusion: it looks like most implementations are libraries, not complete solutions. I have found only OAuth2lib to provide a 'generic' AS that is ready-to-go. The downside is that it completely trusts the client to supply who's logged in, without any way to check that the IdP asserted this. Two options were mentioned to fix this. Both require some coding work.

There are a number of ways to get an OAuth2 access token. One of them is using an assertion. Another is using client credentials, or by means of a refresh token. OAuth2lib seems to support only client credentials with a form of assertion (who's logged in). When in the future other ways to obtain an access token would be required, it's advisible to look more into the other libraries that already implement these.

If the client can be trusted fully, OAuth2lib can be used directly.

Assertions

OAuth 2 supports assertions, including SAML. See also SAML-to-OAuth2 on Azure ACS, Salesforce's assertion flow, Google's assertion flow.

Authorization vs. authentication

OAuth 2 is about authorization. The client (which can be a web portal) communicates with the AS, which is the PDP (policy decision point). The RS is the PEP (policy enforcement point). These two roles can reside at the same location, if it is desired that the decision is made at the RS.

OpenID Connect adds authentication, by introducing an id_token. This is given by the AS to the client, along with an access token for the RS.

It is also possible to use structured tokens (with hashes) to add authentication to OAuth 2 (his is also explained in "Token Format" below).

OAuth 2 Profile

While the OAuth 2 standards (to be) provide a basis to work on, there are a couple of decisions that need to be made when creating an implementation.

  • OAuth flow(s)
  • Client authentication method
    • none
    • client_secret in Authorization HTTP header
    • client_secret in request
    • client assertion
    • X.509 client-side certificate
    • ... (e.g. IP-address)
  • Signature algorithm(s)
    • either using a shared secret: each source-endpoint combination needs to have their own key
    • or asymmetric cryptography: more scalable but used less (in OAuth 2)
  • Token format and token contents
    • two types of tokens (which can be equal)
      • as obtained from the authentication endpoint
      • as obtained from the token endpoint
    • either the token itself contains details about the user, or it is obtained separately by an API call
  • How to pass token with API call
    • In Authorization HTTP header
    • As part of HTTP parameter
  • whether and when to use refresh tokens and/or expire tokens
  • Which OAuth draft to use; there are minor differences between them, e.g.
    • method in the Authorization HTTP header: OAuth or Bearer (and token was spotted in the wild)
  • ...

Token format

An access token is generated by the authorization server, and passed to the resource by the client. The resource checks if the access token is valid, before it returns its response. This checking can be either done via a call to the authorization server, or locally. In the first case the token is opaque to anyone but the authorization server, in the latter case the token needs to be structured and contain a signature that the resource can check. This signature can be either symmetric or asymmetric.

Delegation

What we consider 'delegation' is also called 'n-tier delegation', to stress that services can delegate to other services. In other places, delegation is also used for the separation of AS and RS (the RS delegates authorization and certainly authentication to the AS). We want to use delegation to enable service chaining while maintaining security.

  • Service receives token and can use it as a token for other services (no or wide target audience in token)
  • Service contacts AS / delegation service to receive a new token
    • where does the delegation service run?
      • centrally
      • at/near service / serviceprovider
      • at/near client

Future

How would the landscape look like in the future, and what does that mean for the authentication/authorization landscape?

  • Many services
  • Services requiring the use of other services: delegation
  • Possibly: multiple ASes
    • combined with delegation: services needing to contact different ASes
  • Possibly: service discovery

This is still mostly unexplored territory within OAuth 2.

Before we can move forward with multiple OAuth implementations that have some hope of having an AS work with a remote RS etcetera and multiple clients, the client using the same protocol to talk to multiple authorization servers, wild and crazy ideas, but what we want to get to. Having some notion of how we're all going to do discovery, is a first step that we need to take on that road for interoperability: a client across multiple authorization servers. --- John Bradley in Web Authorization Protocol WG meeting, March 29, 2012 ~1:08

Retrieved from "https://wiki.nikhef.nl/grid/index.php?title=CLARIN/OAuth2&oldid=9222"