[foaf-protocols] FOAF+SSL delegation: logging in to an HTTP server
Bruno.Harbulot at manchester.ac.uk
Wed Mar 25 00:28:12 CET 2009
I've just done a Java implementation of what I had described in
(and discussed again in the e-mail I'm replying to.)
This implementation is available in a Git repository (but tar files can
also be downloaded) at:
There are SAML libraries for PHP which should be able to interact with
this (either as IdP or SP).
Here is part of the README file:
This is a Identity Provider (IdP) and a Service Provider (SP)
implementation to allow an non-SSL website (the SP) to use a FOAF+SSL
trusted authenticator site (the IdP).
This uses the SAML HTTP Redirect Binding  (Section 3.4).
The implementation is based on OpenSAML  (which uses Apache XML
security, Santuario ) and on the FOAF+SSL verifier in the Sommer
project . The tests also use BouncyCastle, Jetty, Restlet and jSSLutils.
__ Status __
This is work in progress, but this should provide the minimum required
for Servlet integration.
The Restlet integration is a very early draft.
Both the SP servlet and the IdP servlet come with jUnit tests which
demonstrate how they work.
__ Sample SAML assertion __
___ Signed response ___
<?xml version="1.0" encoding="UTF-8"?><samlp:Response
Because we assume the SP trusts only one IdP (and the SP knows the IdP's
public key), we can omit the key value in <ds:KeyInfo/>. We just use a
name as an indication.
___ Signed assertion, without the signature ___
- the ID of the subject:
- an authentication with a time:
- the intended audience for this assertion:
___ URL query encoding ___
The SAML assertion above is encoded in the query in this form:
This makes a query parameter which is about 1000-character long.
Bruno Harbulot wrote:
> Hi Toby and Melvin,
> Toby Inkster wrote:
>> Started writing this yesterday, but then I decided to stop and come back
>> to it later. Haven't had an opportunity to put any more thought into it
>> yet, but thought I'd forward my thoughts so far...
>> On Wed, 2009-03-18 at 00:54 +0100, Melvin Carvalho wrote:
>>> 1. Consumer redirects User Agent to a FOAF+SSL service provider with
>>> known public key
>>> 2. User authenticates, and service provider signs the webid with
>>> private key, redirecting User Agent back
>>> 3. Consumer decodes with public key authenticates as webid
>>> Issue: possible replay attack, but this can be repelled by also
>>> sending a timestamp/nonce pair to be encoded also
>> This will work. Possible version avoiding replay attacks would be:
>> Service Provider (SP): website wanting to provide an authenticated
>> service, but lacking the ability to provide HTTPS in general, or FOAF
>> +SSL in particular. We'll assume their domain name is example.org.
>> User: person with a FOAF+SSL-enabled certificate installed in their
>> browser, and wishing to use SP's service.
>> Authentication Service (AS): suitable FOAF+SSL website. We'll assume
>> their domain name is secure.example.net.
>> 1. AS provides SP with its public key. This is done beforehand.
>> 2. SP publishes a public key at http://example.org/key.txt (or any other
>> URI at their domain). This is done beforehand.
>> 3. SP redirects User to http://secure.example.net/as, providing AS with
>> the following parameters in the query string. An [e] indicates that a
>> field is encrypted using AS's public key and signed using SP's private
>> * Return URI (URI it wants the User to ultimately end up at) [e]
>> * Current timestamp [e]
>> * Public Key URI
> I'm not sure we need to encrypt and sign here. The request to the AS
> will be done over SSL between the user's browser and the AS. The return
> URI will be the same as the one the user was trying to access in the
> first place (so someone between the user and the SP would know it anyway).
> For this reason, I don't think the AS needs to know the SP's public key:
> steps 2, 3(e), 5, 6 and encryption in 8 (not signing) could be removed.
> (Unlike Shibboleth, which discloses only certain attributes to certain
> SPs, we're just verifying the ID here. The SP can get further
> information from the FOAF files itself later.)
> If we do want encryption of the WebID between the user's browser and the
> SP in 8, we need to use the SP's public key indeed. My guess is that,
> since the communication between the user and the SP would be encrypted
> anyway, an eavesdropper could find out the WebID quite easily
> (especially if the page says "Welcome <http://example.com/#user>!").
>> 4. AS authenticates User with FOAF+SSL. It may offer additional
>> services, such as alternative authentication methods if the user has no
>> FOAF+SSL certificate installed in their browser.
>> 5. AS fetches SP's public key (preferably checking a cache first) and
>> decrypts the other request fields.
>> 6. If the host name of the return URI and the host name of the public
>> key URI do not match, AS raises an error. (Is this unnecessary?)
>> 7. If the current timestamp param is "old", then AS raises an error.
>> 8. AS redirects User to the return URI passing additional query string
>> parameters. An [E] indicates that a field is encrypted using SP's public
>> key and signed using AS's private key:
>> * Current timestamp [E]
>> * User's WebID [E]
>> This should make it possible for any service provider to use the AS
>> without having to pre-register any encryption secrets with the AS.
> We could use a nonce instead of the timestamp to prevent replay attacks.
> If using SAML, the response could look like Section 188.8.131.52 of
> (with a much simpler <saml:Assertion>/<saml:Subject> that would only
> contain the WebID).
> The downside of this type of response is that it's still a bit big for
> being passed as a query parameter (hence the reliance on automatic POST
> upon a GET in Shibboleth).
> Best wishes,
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
More information about the foaf-protocols