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

[Story Henry]

By the way, this is some of what I blogged about in
"sketch of a foaf+ssl+openid service"

http://blogs.sun.com/bblfish/entry/sketch_of_a_foaf_ssl

And indeed this does not take into account the problem of passing  
attributes from the "foaf+ssl+openid" service
to Juliet's server. But I think that is good thing too. After all that  
service should just do the login part, the piece that
requires the client to connect via https to the server.

If :romeo's server itself wishes to reveal more or less to Juliet,  
using foaf+ssl itself, it should not grant that to the foaf+ssl+openid  
service,
as that could be serving as a login service for many other services.  
Juliet's server should log in with its public key for more  
infomration. Luckily there is no problem
making SSL connections. Just it seems, receiving them.

Henry

On 18 Mar 2009, at 14:50, Bruno Harbulot wrote:

> 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.
>
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols