Difference between revisions of "CLARIN/OAuth2 use case"

From PDP/Grid Wiki
Jump to navigationJump to search
(→‎Use-case: CMDI catalog: add google oauth java client)
(→‎Use-case: CMDI catalog: add spring security oauth)
Line 17: Line 17:
  
 
* [http://code.google.com/p/google-oauth-java-client/wiki/OAuth2 google-oauth-java-client]
 
* [http://code.google.com/p/google-oauth-java-client/wiki/OAuth2 google-oauth-java-client]
 +
* [https://github.com/SpringSource/spring-security-oauth/wiki/oAuth2 spring-security-oauth]
  
 
== Authorization server ==
 
== Authorization server ==

Revision as of 12:22, 17 October 2012

<sidebar>

</sidebar> While in the end n-tier delegation is needed withing CLARIN, for the current use-case it is enough to do without real delegation. Plain OAuth2 is sufficient, just to get some experience with it. Delegation can be added later by using a delegation endpoint, or using certificate delegation.

So the goal now is to create a straightforward OAuth2 setup with client, authentication server, and resource server.

Client

There are many OAuth2 clients for various programming languages. Documentation of the settings needed is most important. It would be useful to have a number of examples to use with the most important programming languages (at least Java and PHP). Finally, a way to configure a client with Apache configuration without touching its code, would be a bonus, supplying user and token information in environment variables.

Use-case: CMDI catalog

The CMDI catalog is Java-based using mod_jk. It uses servlet security, with mod_shib for single sign-on. Options:

  • client library a Java client library to integrate within the portal for obtaining a token
    • portal needs to be web-based, because obtaining a token requires the user's web browser
  • reverse proxy/servlet that always requests an access token after logging into the portal.
    • pro: portal doesn't need to change much / con: token not always needed

The former is cleaner, since it only fetches a token when it is needed. It is probably also easier to implement, and there is quite a number of existing client-side OAuth 2 libraries.

Authorization server

The OAuth2 AS (authorization server) is the most complex component of the three, which handles user authentication using SAML SSO, consent, possibly some authorization, and token management. It does not need to integrate directly with an existing application (unlike the client or RS). There is not that much choice between existing OAuth2 server implementations currently, and their maturity varies. Options:

Resource server

The resource server needs to verify the access token supplied by the client, and perhaps needs to retrieve user information to base an authorization decision on (since one of the requirements is that resources can make the final decision). This is no more than a simple REST call to a check-token or user-information endpoint on the authentication server.

To make this easy for service developers, at least clear documentation is needed on how to do this. It would be useful to have code samples in a number of programming languages.

To complete it, a way to run the service directly on Apache, with just some extra configuration for doing the check and returning information in (environment) variables, would be great. This may include running a reverse proxy that does the authorization, and passing the request on to the real service upon success.

Use-case: ISOcat

In our use-case, ISOcat is the resource server. While many services use servlet filters for security combined with mod_shib for single sign-on and mod_proxy, ISOcat uses Netkernel. Options would be:

The use of a reverse proxy would be the most flexible. If it also integrates well with servlets (which often do use a reverse proxy already), then this would be a fit solution.