Shibboleth Developers

For today's call:

At the bottom of this note, I've pasted in a step  by step definition 
of the LS flow using Shibboleth. I've attempted to extract from that 
set of numbered steps the additional requirements that LS would 
impose on a Shib implementation.

Draft of topics to be covered in an LS profile of Shib:

1) the AA MUST support creating Assertions consistent with HoK 
confirmation method. Defined in Section 5.1 of 
oasis-sstc-saml-bindings-1.1.pdf. An  Assertion containing this 
confirmation method will only be issued in response to an 
<AuthenticationQuery> submitted overan SSL tunnel. The key inserted 
into the <ds:KeyInfo> element will be the key used to establish the 
SSL connection.

2) AA MUST sign Assertions (I believe it already can do  this...)

3) the AA recognize that an entity is requesting attributes about 
itself. This probably is outside the scope of the Shib 
Arhc/protocol... but needs to be defined somewhere.....

Comments please.....

---- Proposed Flow for LionShare using Shibboleth ---------------------

0) Peer 1 obtains local authentication credentials

1) Peer 1 generates 2 RSA keypairs, creates a connection to the local 
SASL-CA, authenticates, and sends both public keys to the SASL-CA.

2) SASL-CA uses the authenticated identity to retrieve attributes 
from the local attribute repository to construct appropriate 
certificates. (LS is using Shib's AA code, so the repository 
interface has been generalized in the same fashion.)

3) SASL-CA builds and returns two certs to Peer 1. The server cert 
contains the identity of the person operating Peer 1; the client cert 
does not contain identity (rather, it has an encrypted handle in the 
Subject field). Both cert's are signed by the local SASL-CA, which 
should be using a cert whose "trustworthiness" can be proven using 
the federation supplied trust files.

4) Peer 1 sends a Gnutella Query message to its Ultrapeers

5) The Ultrapeer routes the query to other Lionshare peers.

6) Peer 2 returns a QueryHit message. This includes a metadata 
structure signed with Peer 2's server cert. In this metadata is a 
list of the attributes which must be supplied in order to retrieve 
the desired object (the metadata does not specify what values are 
required).

7) The UltraPeer routes the QueryHit message back to Peer 1.

8) Peer 1 opens an SSL connection with the local Shibboleth AA; it 
uses its client cert to create the SSL tunnel. (The client cert is 
used because the AA will have to create the AttributeStatement's with 
Holder of Key confirmation, and the attributes should be bound to the 
client cert. ) Peer 1 sends a SAML Query Request request containing 
<saml:AttributeDesignator> elements for the attributes which are 
desired.

The AA will need some way of determining that a user is requesting 
his own attributes (and thus to bypass the ARP code).

-- how to do this? handle in cert refers to same person as the 
enclosed Subject element?

9) The AA validates  the supplied SSL tunnel, uses the supplied 
<saml:AttributeDesignator> to determine which attributes are desired, 
and uses the handle from the supplied cert to identify the user and 
retrieve values from the user's directory object. The AA creates and 
signs an Attribute Assertion; it places the supplied public key in 
the Subject element so that it can later be used with the HoK 
confirmation method..

10) Shibboleth AA returns signed Attribute Assertions to Peer 1.

11) Peer 1 opens a mutually authenticated SSL connection with Peer 2 
using its client cert.

12) Peer 1 POSTs a request to Peer 2. The POSTed form contains the 
previously acquired Attribute Assertion, and the url of the requested 
resource.

13) Peer 2 validates the supplied Attribute Assertion, using standard 
Shibboleth validation processes. It also performs HoK validation.

14) If necessary, Peer 2 uses the supplied attributes to make an 
access control decision.

15) Peer 2 returns the requested resource over the SSL connection.

Question -- I'm still not sure how we're going to handle the 
SASL-CA's signing cert. We had talked before about not validating the 
client certs when Peer1 makes a connection to Peer2. But when I 
thought about it further, I realized that the AA will have to 
validate the client cert when Peer1 connects to it to get attributes. 
So it looks like we will have to have the SASL-CA's signing cert in 
the federation metadata somehow.

Suggestion -- have the cert used by the SASL-CA rooted in a CA that 
appears in the federation metadata