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

Bruno Harbulot Bruno.Harbulot at manchester.ac.uk
Wed Mar 25 00:28:12 CET 2009

Hi all,

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

Best wishes,


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 [1] (Section 3.4).

The implementation is based on OpenSAML [2] (which uses Apache XML 
security, Santuario [3]) and on the FOAF+SSL verifier in the Sommer 
project [4]. The tests also use BouncyCastle, Jetty, Restlet and jSSLutils.

[1] <http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf>
[2] <http://www.opensaml.org/>
[3] <http://santuario.apache.org/>
[4] <http://sommer.dev.java.net/>

__ 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 
Destination="http://sp.example.com/sp/" Version="2.0"><saml:Assertion 
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="">
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ds 
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

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 ___

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
   <saml:AuthnStatement AuthnInstant="2009-03-24T22:34:20.579Z"/>

This gives:
   - the ID of the subject:
   - an authentication with a time:
         <saml:AuthnStatement AuthnInstant="2009-03-24T22:34:20.579Z"/>
   - 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
>> key:
>>    * 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 of 
> <http://shibboleth.internet2.edu/docs/internet2-mace-shibboleth-arch-protocols-200509.pdf> 
> (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,
> Bruno.
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

More information about the foaf-protocols mailing list