Difference between revisions of "CLARIN/Security for web services"
m (→Approaches) |
m (→Approaches) |
||
| Line 4: | Line 4: | ||
== Approaches == | == Approaches == | ||
| − | There are different ways of tackling the issue, but only some can survive. (In the diagrams solid lines are browser redirects, dashed lines | + | 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.)'' |
<div style="clear:right"></div>[[Image:Approaches_open.png|150px|right|Open diagram]] | <div style="clear:right"></div>[[Image:Approaches_open.png|150px|right|Open diagram]] | ||
Revision as of 14:52, 23 March 2011
Approaches
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
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
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
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.
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.
Links
Standards
- User Managed Access (UMA) has some overlap with this work
- OASIS Web Services Security: WS-Security, username, X.509, SAML
- A SASL and GSS-API Mechanism for SAML, uses base64 encoded SAML request in URL
- OAuth 2.0, and with SAML assertions
Libraries
- OAuth 2 assertion profile library
- Shibboleth ECP delegation, web-service client, and configuring it.
