Shibboleth Developers

Some detail, for one of the agenda items in this afternoons call.

The LS P2P service will implement security in two different ways.

-- if the LS client (the entity requesting the resource) and the LS 
server (the LS peer holding the desired resource) are both members 
of a common federation, then they will be able to use a variant of 
the Shibboleth/SAML protocol.

-- if they are not members of a common federation, they will be able 
to exchange self-signed cert's in an out-of-band fashion and use 
those to authenticate.

This text is concerned with option 1, and will not address option 2.

A quick summary of the steps involved in an LS retrieve. The LS 
client will generate two pairs of keys, and then obtain two different 
cert's from the local SASL-CA. The client cert will be 
pseudo-nonymous; the server cert will provide identity info.

Once the user  has identified the resource to be downloaded, the LS 
client will connect to the local Shib AA, authenticate, and obtain a 
set of Attribute Assertions to be presented to the LS server. The 
Subject element in the Assertions will contain the LS client's public 
key.

The LS client will then issue a HTTP POST to the LS server; the form 
will contain the Attribute Assertions.

The LS server does not really  have to do any validation of the cert 
used by the LS client to create the SSL tunnel. It doesn't matter 
where this cert is rooted. However, there are three items that have 
to be checked:

-- do the assertions *really* apply to the LS  client? This 
validation is done using the Holder-of-Key method. Essentially, the 
assertions refer to the entity holding the private key that matches 
the public key found in the subject element. The LS  client used this 
private key to create the SSL tunnel.

-- are the assertions signed by a known entity? The signing cert used 
by the AA must be the expected cert (as defined in the federation 
metadata). A rude summary of the algorithm would be:

        -- get the issuer value

	-- map thru the federation sites and trust files, to obtain 
the keys that should be used to validate the signature on the 
assertion

        -- validate the signature.....

-- standard Shib attribute acceptance filtering