Re: Introductory note for SSO proposal

Hi Doug,

here's some preliminary thoughts on your questions.

On Thu, 1 Jul 2004, Doug Tody wrote:

> Guy -
>
> This looks good, but it would be very helpful to do a walk-through of a
> typical use case to illustrate in concrete terms what is being proposed,
> down to the level of the specific software required to implement such
> a capability.
>
> For example, suppose we have the following scenario:
>
> o Site A maintains a user database of all users of the facility.
> Probably we want to associate the central sign-on authority for
> the site with this user database. When a user first accesses
> the system, e.g., via a Web page, or via a remote Java client,
> we somehow authorize the user with this authority.

Site A can play it one of three ways.

1. Trust unknown users if they come from Community X, which A trusts a priori, and register automatically in A them when they first show up at A. Wil has suggested this approach for MyDB.
2. Don't trust unknown users coming from X, even if the X community is trusted; don't register unknown users automatically. Instead, poll X regularly (e.g. nightly; interface TBD) and register in A all users in A that are unknown to A.
3. Require users to register explictly and manually at A, stating their identity in X. Trust warrants from X to prove the identity of users, but don't let them into A if they haven't registered in A.

Any of these work.

#3 is more reassuring for service providers perhaps, since it allows more checks and balances. However, bear in mind that the admins of X may decide to pre-register all their users in A when they join X. This would seem to be a Good Thing for X and the users but reduces the strength of A's defenses.

#2 presumes that there is some interface at X whereby A can ask for security assertions about members of X. This is comparable to a Shibboleth asking a community for SAML assertions at the time of authentication. We may need to make this interface anyway.

> o The user runs some Java client, say a proposal submission tool,
> which wants to query a database at the site, and ultimately
> update information in the database. The Java client will need
> to authenticate with the master sign-on authority for the site.
> This presumably returns some sort of ticket back to the client
> which it can then pass off to the database front-end to gain
> secure access. How does this work and what software is used?
> What is the lifetime and scope of the ticket? Can it be passed
> around to different clients on different computers or possibly at
> different sites? How? We will need different "communities" as you
> say, e.g., for PIs and their CoIs, for the TAC, for the local staff,
> and so forth. A single person might be in more than one community.

If the "master sign-on authority for the site" is the user's home community, then yes: the community issues tickets in the form of SAML assertions that the user's agent can add to authenticated messages. Bear in mind that one service site typically trusts several, possibly many, communities to issue these credentials; there's no single, master SSO site.

Ticket (warrant) lifetimes around a day sound good to me. The scope of the ticket is all the service sites that trust the issuing community; potentially the entire VO.

A given ticket is tied to a public-private key-pair of which the client holds the private key (that's how it can sign the messages). Different clients of the same user have different private keys, so have different tickets, but the tickets are for the same identity.

PIs. CoIs and staff for the same mission, say, might be different groups inside one community.

> o The same authorization mechanism would then be used to retrieve
> data from the archive. Again, this could have various front ends.
> A typical scenario might be for a user or client program at site
> A to perform a query to site B and pass a secure request to site
> C to initiate a third-party transfer of the data back to site A.
>
> Each site would want to maintain its own user database and authentication
> mechanism since this same mechanism would probably be used for internal
> operations. We might need to gateway whatever is used internally to
> whatever is used for site-to-site authentication within the VO, or perhaps
> this could be another example of a community.

I see the user database being for internal authorization: you convert the external identity to an internal identity and check the authorization of the latter. The SSO authentication doesn't need a user database at the service site since it works of the external identity.

Cheers,
Guy

Guy Rixon 				        gtr-at-ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523