Shibboleth Developers

This is pasted together from several other people's notes: Mark 
Earnest, Von's grid use case, and private email with Bill Doster.. 
I've  also done editing, and added some additional steps.

This is for discussion on the 1/12/2003 conf call. Post 
questions/comments to email before the call, if possible.

-- The client generates an RSA key pair, and sends a kerberos service 
ticket  and the public key to the KCA server, which authenticates the 
user.

* The  KCA creates a new short-term certificate for the user with a 
handle as subject name (or more likely encoded as part of subject 
name - e.g. as common name). The certificate contains a non-critical 
X.509 extension with pointer to AA. Don't currently think that the 
cert needs to contain a signed SAML Authn Assertion?

Q. How long does this cert live? I'm imagining we will also automagically
(or by re-prompting the user for uid/pw) get a new cert signed in the
event the existing one expires.

-- It is *NOT* a proxy cert that is returned.  The cert is signed 
with the KCA's certificate.

-- The client sends out a search request over the p2p network. The 
server with a file matching the request returns the metadata for the 
file and a list of attributes required by the policy associated with 
the file. The metadata is signed by the user making the resource 
available.

(Q: what key pair is used to sign the metadata? A permanent key,or a 
temporary one obtained via KX.509 when the publisher started their LS 
client? )

(from mark): Really only two ways to do this, either (1) the client 
generates a keypair
and gets the cert signed (like the earlier example) and uses this to sign
stuff, or (2) the metadata is sent to a separate machine which signs it
after the user has authenticated to it.
(1) tells the best story with regard to performance and ease of use
(2) allows us to have a much longer lifetime on the signing cert but adds
overhead and might be a bit complicated.

I suppose there is also the option to issue long term certs to users to
use for signing, but nobody has really succeeded in doing this for S/MIME,
so I hesitate to try and build/deploy that infrastructure for Lionshare.

(end Mark)

-- The client sends a download request over an SSL connection to the 
server that it opens using the certificate it had obtained from the 
KCA.

* Target service determines the appropriate AA for the user from
extension in proxy certificate.

* Target service contacts the Shib AA over a SSL protected
channel. Local, trusted copy of certificate of Shib AA is used to
verify that the correct AA is being communicated with. Target service
performs mutual authentication with shib AA using it's own certificate
& private key.

(Q: what cert  does  target use to  create SSL tunnel, and thus 
establish identity? a temp one,  signed by its local KCA? If the 
target has a cert that it used for signing, that could pull double 
duty as a client SSL cert. )

* Target service presents cert with handle/subject name for user and requests
attributes for user.

-- Shib AA verifies that cert w/handle is signed by local KCA

* Shib AA consults ARPs to determine target service's right to access
attributes for handle/user. Delivers list of attributes to target
service over SSL-encrypted link (don't see any need for signing of
attributes).

* Target service uses attributes along with local policy to make
access control decisions.

-- The server releases the file to the client.