[foaf-protocols] FOAF+SSL delegation: logging in to an HTTP server

Bruno Harbulot Bruno.Harbulot at manchester.ac.uk
Wed Mar 18 14:50:23 CET 2009


Hi Melvin,

Melvin Carvalho wrote:
> On Wed, Mar 18, 2009 at 2:41 AM, Bruno Harbulot
>> Let's call the User <https://user.example.net/#me> who has photos on the
>> Service Provider (SP) <https://photos.example.net/#sp> and who wants to
>> print them using the Consumer <https://printer.example.org/#c> (to make an
>> analogy with the OAuth examples.)
> 
> This is just a login example, nothing as complex as OAuth.  The
> principle is that the Consumer is a low tech server with no access to
> https, and wishes to delegate the FOAF+SSL authentication to a
> (trusted) 3rd party, the Service Provider, in order to find out the
> WebID of the User, and whether it is authentic.

Ah, so that's not quite the problem OAuth is addressing. It is, however, 
the problem that Shibboleth is addressing. These are similar problems, 
but the aim of Shibboleth is to delegate the authentication process to a 
3rd party (rather than delegating the credentials for being used by a 
3rd party).

Just to make things easier, OAuth and Shibboleth use 'Service Provider' 
to mean two different things. (A loose parallel could be OAuth SP <-> 
Shib IdP and OAuth Consumer <-> Shib SP.)

In OAuth, the User delegates some of its credentials to the Consumer so 
that this Consumer can access resources on the Service Provider. This is 
done by having the Consumer redirect the User to the Service Provider to 
grant the access token.

In Shibboleth <http://shibboleth.internet2.edu/>, the User tries to 
connect to the Service Provider, which delegates the authentication task 
to the Identity Provider (IdP). The user authenticates the User (which 
it knows), creates a SAML assertion and sends it back (via another 
redirect in the browser) to the SP. This SAML assertion is then verified 
(there's a pre-established trust established between the SP and the IdP) 
and this authenticates the User to the SP. (I'm simplifying a few things 
here, because there are attribute release policies, etc.)

The actual authentication mechanism chosen to do the authentication on 
the IdP is totally flexible. FOAF+SSL could be used.
In Shib, there's also a WAYF service ("Where Are You From") that between 
the SP and the IdP, so that the user can choose the IdP from his/her 
institution.

This is what the Shib interaction looks like from the browser point of view:
>    1. C->S - GET. The browsers attempts to get http://protected.site/page.
>    2. S->C - The server returns a 302 redirection to a "Where are you from?" (WAYF) page, this URI includes the URI of the protected page in a parameter.
>    3. C->S - GET http://where.are.you.from/ (automatic after redirection).
>    4. S->C - The WAYF page offers a list of identity providers (IdP). The user clicks on an IdP link (usually, that of his/her institution) and is directed to that URI. Again, that URI comprises the URI of the protected page.
>    5. C->S - GET http://identity.provider/. The page of the IdP authenticate the user via another means (HTTP Basic, X.509 certificates, ...): this is where the IdP authenticates the user.
>    6. S->C - Upon successful authentication, the IdP gives the browser a web pages with a form that contains the SAMLResponse. This form is instantly submitted automatically via POST (because there's a <body onload="document.forms[0].submit()"> on that page).
>    7. C->S - POST to http://protected.site/Shibboleth.processor the content of SAMLResponse.
>    8. S->C - The server sets a Shibboleth session cookies and sends a 302 redirection to the original protected page.
>    9. C->S - GET http://protected.site/page. The Shibboleth authentication has taken place. The Shibboleth-protecting module also inserts automatically a header for processing by the web application it hosts. That header is a set of SAML assertions for authentication and authorisation.
>   10. S->C - You're in (depending on the SAML assertions).




> 1. The Consumer (which is not HTTPS enabled) redirects the User Agent
> to a (trusted) FOAF+SSL authentication service.  The public key of the
> Service Provider is previously known to the Consumer.
> 
> 2. The User authenticates with the Service Provider via FOAF+SSL and
> at this stage the User's WebID becomes known to the Service Provider.
> The Service Provider then uses its private key to sign the User's
> WebID, which it then passes in a parameter, while redirecting the User
> back to the original Consumer.
> 
> 3. The Consumer decodes the encrypted WebID, belonging to the User,
> using the Service Provider's public key.  This enables the Consumer to
> know the WebID of the User, and that it was authenticated via a
> (trusted) 3rd party.  The Consumer now knows the Users's WebID and can
> safely log the User in.

So, that's more or less the same process as Shibboleth, without the WAYF 
step. The Consumer here is <http://protected.site/page> (SP in Shib) and 
the IdP is the FOAF+SSL authentication service.

It's true that, due to the global nature of the FOAF+SSL identity, the 
WAYF isn't really required. There still needs to be a pre-established 
trust relation between the IdP and the protected site (which seems fair 
enough). This still involves a few steps (and there are additional 
back-end channels in Shib).

Shib also addresses the problem of which attributes the IdP can release 
to which SP (that is, what a particular SP is allowed to know about the 
user). That's something that could be addressed differently in FOAF+SSL, 
by having the protected site query the FOAF file of the user directly 
(in which case the FOAF host might choose not to release everything).

I don't really like the way Shib passes tokens around (via "POST-on-GET" 
using <body onload="document.forms[0].submit()"> in particular). That's 
however the kind of trick that's going to be required.


Best wishes,

Bruno.



More information about the foaf-protocols mailing list