Shibboleth Developers

[Von Welch <>]

David,

 If I roughly summarize your last few notes, your basic gist is that
the shib handle makes solves the inter-organization authentication
problem and the Grid should use it instead of bringing DNs into the
Shib space.

 I think you raise a good point and have changed my thinking
somewhat. Let me raise two points from my side first and then dive
into a modified use case of my own.

 First, the Grid is already in bed with the inter-organization
authentication problem. You can argue this is bad, but let's do that
some other time.

 Second, many in the Grid community are going to have a problem with a
bearer credental (which is what I understand the shib handle to
be). They will want to have a binding back to a key proven to be in
posession of the user.

 So the new use case I'd like to suggest is a modified version of my
original use case #2, basically overlay the shib handle system on top
of the Grid credential system, allowing the shib model to stay mostly
unchanged while addressing my second point above:

1) User authenticate to local service, very similar to the exiting
handle service, and gets back a handle. Handle is also put into shib
AA as it would normally be done today.

2) User bundles handle with Grid credentials, authenticates to target
service (by bundle, I probably mean stick in as noncritical X.509
extension, but that a detail).

3) Target service takes handle, basically acts like a SHAR - it
contacts shib AA with handle and everything proceeds as it normally
would with Shib today.

So this is pretty similar to Shib today, the only difference being
that instead of the SHIRE and browser redirection to get the handle,
the user contacts some modified handle service first and bundles it
with their Grid credentials.

Now let me add one twist - Add something to the handle to accomodate
the "identity" of the user. The modified handle service above could
stick that identity into the handle and a target *who cares* can
verify ownership of the handle and hence get a path back the posession
of the private key (my second point above). Note that a target that
does care (for whom a bearer credential is acceptable) can skip this
step and treat the handle opaquely.

Comments?

Von

David L. Wasley writes (11:18 January 15, 2004):
 > 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
 >