[ogsa-authn-bof] Use Cases

[Tom Scavo]

On 2/15/07, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
>
> the solution to the dilema you describe below, is for the authz service
> to completely ignore the user ID (ePTID) that is provided by the CA

In that case, there's no need to bind the ePTID to the DN or any other
part of the certificate as others have suggested.

> and
> instead to require the IDP to provide the user's globally unique ID as
> part of the set of authorisation attributes.

What globally unique ID?  Are you referring to something like
eduPersonPrincipalName?

> In this way the grid
> service can be sure to uniquely identify the user, regardless of the
> path taken, or gateway that was used, to access it.

I'm not quite understanding your suggestion, David.  Are you talking
about Attribute Pull?  If so, there's a catch-22, since the Grid
Service must supply a SAML Subject in the AttributeQuery.  That's a
problem, and it's exactly why we've chosen to concentrate on Attribute
Push.

> Ultimately there is no way around this problem. The service must have
> access to the user's globally unique ID in order to correctly enforce
> access controls.

Yes of course.  The globally unique ID need only extend to the
boundary of the Grid, however.  I've been trying to make the case (but
not doing a very good job, I'm afraid) that the campuses running
Shibboleth/SAML may not be willing and/or able to supply the globally
unique ID that you require.

> The advantage of this approach is that the IDP can
> encrypt the user's ID attribute using the public key of the ultimate
> service provider, so that the user's privacy is still protected along
> the entire access path.

Well, encryption implies SAML V2.0, which is quite a ways down the
road.  We're rolling out deployments based on SAML V1.1 *today* so
encryption is not an option.  Moreover, encryption doesn't solve the
problem we've been discussing (i.e., a name mapping problem).

Tom