Shibboleth Developers

["David L. Wasley" <>]

The question in my mind is: what identifier that the local (origin) 
domain understands does the GRID resource also understand - i.e. have 
information about so it knows the user is eligible to use GRID 
resources.

This is why I'm focused, in this case, on the EPPN.  If the user 
applies to the GRID and provides as part of that application his/her 
EPPN, then that key can be used in the GRID user database - I must 
assume that there is one or else they wouldn't know who was a GRID 
member, what they can use, how it is funded, etc.

Therefore, Shib could be used to supply the EPPN to the GRID on 
behalf of the user.  It doesn't matter to the GRID how the user 
authenticates locally (Shib philosophy).

Once the GRID knows, reliably, the user's EPPN, it can do whatever it 
wants or need to do: look up stuff in a GRID database or query the 
user's home AA.

        David
-----
At 1:31 PM -0500 on 1/15/04, Scott Cantor wrote:

>  > Whereas the UC campus Handle Server interface needs to understand
> >  this credential, the AA interface (currently) only understands the
> >  HS-generated handle.  Clearly SMOP but ...
> >
> >  The same person's EPPN might be 
> > ""
> >  and I would
> >  assume that a query to the AA for attributes based on this EPPN would
> >  be straight forward.
>
> Sure, but why would I know the EPPN from looking at your cert? Same problem.
>
> >  I suppose we could assume that a campus run AA could be programmed to
> >  accept a campus generated cert full SubjectName as a query key.  At
> >  UC, all we'd need is the CN= but we I don't think we can assume this
> >  would be true everywhere.
>
> The AA can do just about any of that with a plugin, but I think the target
> shouldn't have to make a lot of decisions about it. That's why sending the
> whole cert always seemed attractive to me even if you still wanted to do
> path validation at the target.
>
> -- Scott