[foaf-protocols] more saml2 foaf+ssl hybrids, using sp-initated websso with artifact binding

Peter Williams pwilliams at rapattoni.com
Sat Dec 5 22:37:51 CET 2009

If you are in the mood... below I play with  2 variant SAML2 flows, called idp-initiated and sp-initiated artifact bindings. I linked their signals to foaf+ssl. The first goal was to eliminate the need for an RP to have a trust model describing the certs of the SSL servers from which the foaf files are sourced, during foaf+ssl message processing. The second goal builds upon the first, to derive per-graph derived authenticated connections operating within the HTTP protocol (vs a transport channel).

So... let's get started on a long mail.

Delete now...

Over a foaf+ssl authentication channel (delivering the user's client cert etc), user's browser does a GET on a server with interesting resource objects, using a URL that bears a reference number.  The point is to first get an "authentication session" in a cookie, whose id and roles will then authorized access to particular named graphs and particular namespaces. The GET may look a bit like. GET /saml?SAMLart=AAQAAGDz8sH0F192389ekHMQ3DLO7usMr6Ynp9r49kIc6DPoiIsIUDzlnQI%3D HTTP/1.1

Over https, the RP then pulls the XML formatted assertion, citing the SAMLart refnum. (Yes, the pull uses the evil soap vocab, wrapping a few extra xml tags around the de-referenced assertion returned). HTTP Basic auth and HTTPS provide the mutual  authentication for this process, authenticating the intended sink with a password and authenticating the assertion source with a ssl handshake.

Rather than use basic auth over https, now let the pull of the saml assertion document be foaf+ssl (with a view to enabling the server with "interesting resources" to authenticate to the assertion repository, using its own endpoint's client cert, embedded webid (& associated foaf file)) .

In one trust model governing resource servers (particularly those acting for servers wanting to act or the user in delegation situations), the assertion repository will accept any public key for the client cert for the resources server's endpoint, providing it is bound particular whitelisted subject name in the cert (with an cn=<webid>  attribute value assertion).

Obviously anyone can get the assertion when using the foaf+ssl option! But access control is not the point... The point is to allow the assertion repository to go and get the foaf file of the webid of the resource server, from which to perform access controls and encorce grust models based on foaf cards.

The assertion document that the resource server retrieves over foaf+ssl is dynamically signed by the assertion repository - and it has a particular nameid element, bearing the same user's webid as was presented in the foaf+ssl client cert cited earlier by the browser.

When the SP pulls the assertion document (and decodes the webid field from the nameid tagged element), ONLY NOW does it pull the user's foaf file by deferencing the user's webid.

The lifecycle of the user's foaf file on the resource server is NOT controlled by HTTP caching, but is explicitely controlled (for foaf+ssl purposes) by expiry and other reliance-control signals in the assertion. The assertion is a "control" document, that that specifies who may rely upon the user's foaf graph for what purposes. It may impose privacy and copyright notices, for example. Its signed metadata....(much like signed XRDs in openid land)

Assuming the resource server's own foaf file is viewed as trust store, let's assume the store has a public key for the signed assertion document (and the assertion's signature verifies). In this case, one can let the SP now further rely upon a specific attribute in the assertion - treating it as the sha256 hash of the (user's) foaf file tied to the (user's) webid. The SP only relies upon the (user's) foaf file if the stream's hash (given some canonicalization and serialization of the graph) matches that in the attribute from the signed assertion document.

If one does all this, there is no need for the resource server to have the public key of the https server from which the foaf file is retrieved. The signed saml assertion is indirectly dynamically signing the foaf file, by including the foaf card's current hash within its signing block.

So far, we have only used what is called idp=initiated websso. Now, we get to use a more complex variant which basically adds an entire copy of the above flow on the front of the flow as we have described - but with roles and initiating points all reversed.

Its purpose would be to authenticate an explicit signed request from the resource server to the asserting authority, before all the above happens. It's all the same process however.. of sending an refnum to the asserting party (which references it to get an signed assertion including a hash of the resource server's foaf file)... which fits into a trust model based on webids.... Which .... If the user accepts the resources server's identity lets the user decide to release his own client cert.... etc which performs the now "sp-authorzed" idp-initiation  leg of the handoff as described earlier.

Of course, since we now have both foaf files being authenticated mutually, one could be including a DH public keys of one or more endpoints in them, so that the hashes with suitable nonces (already present in the assertions authenticationg assertions and requests) generate a shared symmetric key, whose cryptostate can be derived to form "HTTP level connections. This should now start to sound like SSL design... since over any such connection the browser pulls particular graphs in PARTICULAR namespaces (one per connection).As with SSL, carefully use of ephemeral DH keys and security services can allow one to specify and obtain perfect forward secrecy, for the confidential transfer of static graphs (or SPARQL requests/response using graphs, named graphs and queries for signaling higher-layer workflow protocols)

<?xml version="1.0" encoding="UTF-8"?>

<S11:Envelope xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/"><S11:Body><samlp:ArtifactResponse InResponseTo="T8oXPXKWpqvotIOlpJitQ55WI1." IssueInstant="2009-12-05T20:13:44.182Z" ID="aK8M60DuRQvPlXSD-uPepOdLhIA" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">PF-DEMO</saml:Issuer><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status><samlp:Response IssueInstant="2009-12-05T20:13:44.101Z" ID="ZnU3jf3iicV8gthncSgtM6KoL0F" Version="2.0"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">PF-DEMO</saml:Issuer><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status><saml:Assertion Version="2.0" IssueInstant="2009-12-05T20:13:44.105Z" ID="nk3zQdhxXb5HVsyQNc0LuHlfx5r" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"><saml:Issuer>PF-DEMO</saml:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<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="#nk3zQdhxXb5HVsyQNc0LuHlfx5r">
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

</ds:Signature><saml:Subject><saml:NameID Format="urn:peter.org:webid">http://peter.me/card#me</saml:NameID><saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml:SubjectConfirmationData NotOnOrAfter="2009-12-05T20:18:44.105Z" Recipient="http://pingcertification.rapattoni.com/sp/ACS.saml2"/></saml:SubjectConfirmation></saml:Subject><saml:Conditions NotOnOrAfter="2009-12-05T20:18:44.105Z" NotBefore="2009-12-05T20:11:44.105Z"><saml:AudienceRestriction><saml:Audience>PF-DEMO</saml:Audience></saml:AudienceRestriction></saml:Conditions><saml:AuthnStatement AuthnInstant="2009-12-05T20:13:44.105Z" SessionIndex="nk3zQdhxXb5HVsyQNc0LuHlfx5r"><saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef></saml:AuthnContext></saml:AuthnStatement><saml:AttributeStatement xmlns:xs="http://www.w3.org/2001/XMLSchema"><saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Name="Email Address"><saml:AttributeValue xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">john at example.com</saml:AttributeValue></saml:Attribute><saml:Attribute<mailto:john at example.com%3c/saml:AttributeValue%3e%3c/saml:Attribute%3e%3csaml:Attribute> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Name="Member Status"><saml:AttributeValue xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Silver</saml:AttributeValue></saml:Attribute><saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Name="Last Name"><saml:AttributeValue xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Doe</saml:AttributeValue></saml:Attribute><saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Name="FOAF CARD SHA1 HASH"><saml:AttributeValue xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">2fd4e1c67a2d28fced849ee1 bb76e7391b93eb12</saml:AttributeValue></saml:Attribute></saml:AttributeStatement></saml:Assertion></samlp:Response></samlp:ArtifactResponse></S11:Body></S11:Envelope>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20091205/a113a435/attachment-0001.htm 

More information about the foaf-protocols mailing list