CLARIN/Security for web services

From PDP/Grid Wiki
Revision as of 15:21, 23 March 2011 by Wvengen@nikhef.nl (talk | contribs) (→‎Requirements: initial requirements)
Jump to navigationJump to search
  • ISOcat registry
  • CMDI, component metadata infrastructure

Requirements

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)

for the System as a whole

  • Multi-federation authorization, with Shibboleth/SimpleSAMLphp
  • SOAP and REST
  • Using proven technologies
  • Operational effort minimal
  • In-line with standards & best practices
  • Can we start today?

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.)

Open diagram

Open

All services trust each other. No technical security measures (other than, possibly, blocking complete strangers); managable upto ~15 services [TODO ref needed]

Shibboleth + delegation

Shibboleth is already used for federated authentication. It has ECP support with delegation, though only through a plugin. The next major IdP release may include it though.

One cannot expect each IdP to install this plugin, or to have the latest version installed [TODO check if this is the case with Shibboleth version policies]. Therefore this option is not viable.

SAML ECP

(see Shibboleth) [TODO would there be other SAML ECP options than Shibboleth?]

OAuth 1.0 diagram

OAuth 1.0

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 quite a number of big websites like Google, Twitter.

OAuth 1.0 requires browser redirection and confirmation [TODO check if confirmation is optional]. This might be acceptable for the portal scenario, but not for nested service invocations (real delegation).


OAuth 2.0 diagram

OAuth 2.0

OAuth 2 is the next evolution of OAuth (still in draft), which supports many more scenario's. This is being adopted (Facebook is on the wagon already). RedIRIS has already made this work with Shibboleth in OAuth2lib. Here the AS is a token service that is populated by the portal.

OAuth 2.0 diagram

Intermediate Token Portal

Expading 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.

OAuth 2.0 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.

This is not a general solution, but may be a simple solution for this specific case.

Links

Standards

Libraries

Federations

Other