Authentication delegation between services using OAuth2

Components used in test case

A delegation test case was carried out between the Component Registry and ISOcat. Users logged into the Component Registry could access their private ISOcat datacategories without leaving the application and without having to login more than once.

For more info, see ​OAuth2 use case on the NIKHEF wiki.

Resource access delegation

TLA has the plan to modify the way resources are protected/accessed. Currently they are protected through the 'eager' mod_shib Apache module. The plan comprises replacing this with an 'active' facade layer based on lazy shibboleth authentication, i.e. having the possibility to apply logic even when the user is not authenticated. See StreamerProposal? for details on the facade service. This facade server will support OAuth authentication, acting as an OAuth protected resource (see explanation on architecture below). Clients can either directly access the resource, authenticating through Shibboleth, or through another service that will use an OAuth token to negotiate access. The client must obtain a valid token from the Authentication Server (AS) before attempting access to the protected resource. The resource provider will check the validity of the token with the same AS. Hence the architecture depends on a trust relation between the client service and the AS as well as the resource provider and the AS. The end user always decides whether the client service may act on its behalf.

OAuth2 architecture example

The diagram shows three scenarios all of which involve the same IdP and two services: one web applications and one resource provider, all part of different service providers.

In the red scenario, the user uses the web application without any delegation whatsoever, using the authenticating against the IdP, which releases an EPTID 'efgh456' so he becomes known to SP A by that id.

In the green scenario, the user accesses the resource directly. Again he uses the IdP for authentication but this time becomes known to service provider B by id 'ijkl789' since the IdP releases a different EPTID for each SP.

In the blue scenario, the user uses the web application in SP A and wishes to use a resource from SP B through delegation. The application redirects him to the Authentication Server (AS) in SP C, which contacts the user's IdP which releases an EPTID 'abcd123', which then gets associated with the newly created token in the AS. The token is retrieved by the web application, then passed to the resource provider. The resource provider checks the token with the AS and learns that the associated identity is 'abcd1234'. However since the access rights on the user's resources are associated with e.g. identity 'ijkl789' (by which the user was known when he uploaded the resource for example), they do not become available to the web application as there is no way to map the available identity to this specific user.

Used implementations

• Authentication server: ​NDG OAuth Server
• Client library: ​Spring Security with ​OAuth extension
• Resource: custom handling in ISOcat

More information

• ​Getting started guide by Willem van Engen (explaining how to set up the AS and Spring based client and resource)

Planning

• [Done #417] An AS will be deployed in a publicly accessible location for testing purposes soon (October 2013)