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

Wed Mar 25 00:28:12 CET 2009

Hi all,

I've just done a Java implementation of what I had described in 
<http://lists.foaf-project.org/pipermail/foaf-protocols/2009-March/000378.html> 
(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: 
<http://git.kato.mvc.mcc.ac.uk/bruno/samlredirector.git/>

There are SAML libraries for PHP which should be able to interact with 
this (either as IdP or SP).

Best wishes,

Bruno.

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 
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
Destination="http://sp.example.com/sp/" Version="2.0"><saml:Assertion 
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
Version="2.0"><saml:Issuer 
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://idp.example.org/idp/</saml:Issuer><ds:Signature 
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod 
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="">
<ds:Transforms>
<ds:Transform 
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform 
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces 
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ds 
saml"/></ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>ttiIKi8K9Ls5i2djIJO65EOzUBI=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
nsjRKNMRxDXrtcsFrgNDX4Zh0ZwsRyubaGrXQbfphoH+iVbjimpUrb5VXwwUi1Y5cKp4t4khVT05
yEoqz9teovrPdMz3N5UYfYixENv52p896A2sHlSDkpg6pZq7MOOxlDhhQEN/efieRaWnvDYd6ow6
Tm35u2tCH6eC4B/QapI=
</ds:SignatureValue>
<ds:KeyInfo><ds:KeyName>http://idp.example.org/idp/#pubkey</ds:KeyName></ds:KeyInfo></ds:Signature><saml:Subject 
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"><saml:NameID>http://foaf.example.net/bruno#me</saml:NameID></saml:Subject><saml:Conditions 
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"><saml:AudienceRestriction><saml:Audience>http://sp.example.com/sp/</saml:Audience></saml:AudienceRestriction></saml:Conditions><saml:AuthnStatement 
AuthnInstant="2009-03-24T22:34:20.579Z" 
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"/></saml:Assertion></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 ___

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
Version="2.0">
   <saml:Issuer>http://idp.example.org/idp/</saml:Issuer>
   <saml:Subject>
     <saml:NameID>http://foaf.example.net/bruno#me</saml:NameID>
   </saml:Subject>
   <saml:Conditions>
     <saml:AudienceRestriction>
       <saml:Audience>http://sp.example.com/sp/</saml:Audience>
     </saml:AudienceRestriction>
   </saml:Conditions>
   <saml:AuthnStatement AuthnInstant="2009-03-24T22:34:20.579Z"/>
</saml:Assertion>

This gives:
   - the ID of the subject:
         <saml:NameID>http://foaf.example.net/bruno#me</saml:NameID>
   - an authentication with a time:
         <saml:AuthnStatement AuthnInstant="2009-03-24T22:34:20.579Z"/>
   - the intended audience for this assertion:
         <saml:Audience>http://sp.example.com/sp/</saml:Audience>

___ URL query encoding ___

The SAML assertion above is encoded in the query in this form:

http://sp.example.com/sp/?SAMLResponse=nVVdc6owEH3vr2Dw0dGAOtUyakettl61Xr%2
BrbwgLRCFBEvz69RcQ1Dptp9c3Ttg952x2k5Sf944tbMFjmJKKKGclUQCiUR0TsyJOxq1MSXyul
pnq2K4yBOZSwkAIcghTosWK6HtEoSrDTCGqA0zhmjKq9bpKLisprkc51agtCi%2FAOCYqj2Qszl
0FIeZmYa86rg1ZjToBRKIwTawE6eJJWKkxBl6YeSX8s66aZHxN2GbMB%2B8OtmrsHOsX69QzQ4z
K6Iq7WtaZMsJmULHvJRums3Ppu90uu8tHuTlJkpD0hIIYnWEzJVYfkmTQ28SgJ9xQCSVYU218jH
axB9yiulCzTephbjnfUMtIlkLqDOy1jCYXSEpEF4HI3S%2BZPpn0mJphlionZEMwwAsGB4TJsF0
R4xrGnkqYQT2H3eD%2FEwOyBZu6oGdY4jnR%2FT3jFxtRLYOmtIlm%2Bwxv4T3su6tqwOJ2gfZ7
KuGvBwbedzHjFVFnQjgKgccyuvYYWEZf7MoLNoPDcU8XrjtwYpmqtg%2FVnL%2BepBedBd036Oq
Psd%2Fw90G6JffdhVmJLFwHn0ydGxjj2%2FE7T0ucBA3UYz0q9%2BdzsiweCpvWZHWU0ofSUZo8
pruIbda8Dmbf4MXVfJ%2Fu6HmnVp806yQ9p48z3IZZv7iytMOe4PnDoH%2FsNZuvfD2SUTPnrTb
dFeeb1oc5G3WOb9bbcFfczM2Ws5Hr3W2zNl4ZVrvbHNRaaTI4OppmOaUPKk2nhy16feBzS5%2B9
48OyOMnX60XyWBtULjVd1xDW1YFDVGT8HQ7BT4c85frLNRwiuiQ8ASeeT0LxfTPylyvQ%2BD0Xz
okg1Gm%2FJMYMqhpnZwQ4Wno%2BoSkH4isojo5RLB4zNSjRcUjN7ndT83UcjkrwHnAPa%2BGvmz
%2FVb2%2F42NQ58AZ%2FokQ3js8i3CIjrnJwgHAhgm3CuEqCsxcckaeMlM%2FkCuNcTskXlHwx%
2ByiXFuId5aKzu2QpXrg8hdV%2F

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 3.1.2.1 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