Skip to Content.
Sympa Menu

shibboleth-dev - Re: Fwd: More detailed Grid scenarios

Subject: Shibboleth Developers

List archive

Re: Fwd: More detailed Grid scenarios


Chronological Thread 
  • From: "David L. Wasley" <>
  • To: Von Welch <>
  • Cc: Scott Cantor <>,
  • Subject: Re: Fwd: More detailed Grid scenarios
  • Date: Fri, 16 Jan 2004 12:59:40 -0800

Von, Yes - Shib avoids the need for one institution's authentication system
to be understood by another institution. Instead, AuthZ is done locally and
information about the subject is exchanged between trusted institutional
agents on behalf of the subject.

I need a little help understanding your description below.
-----
At 1:59 PM -0600 on 1/16/04, Von Welch wrote:

>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.

The Shib handle has a lot of built-in defenses against replay, etc., so we
believe it's pretty trustworthy.

WRT "key proven to be in possession of the user" what key is that? What if
my local AuthZ is Kerberos?

>
> 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,

What are "Grid credentials?" Are these the certs manufactured by the User?

>authenticates to target service

Do you mean by this that the User offers his/her newly manufactured cert to
the Grid target and the target verifies that it is legitimate and that the
User is in possession of the corresponding private key?

>(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.

Yes, this should be workable.

>
>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.
>
Now you lost me. Anything that the HS could put in the handle also could be
retrieved from the AA based on that handle. The only thing that the HS knows
uniquely is the method of AuthZ that was used at the time the handle was
created. This assertion could be added to the handle (I believe we've
discussed this in another context).

What do you mean by "verify ownership of the handle and hence get a path back
to the possession of the private key"? Let's assume that the handle can't be
captured and replayed, even by the Subject user except in a very limited
sense. Therefore, there is no question of the binding to a known individual.
Also, if the handle has been encapsulated in an x.509 object, and that
object has been verified, then possession of the corresponding pvt key has
already occurred. I can't recall for sure but it's possible that the IP
address of the platform to which the handle was sent by the HS is also in the
handle (again, to avoid capture/replay). So, the binding would seem pretty
secure. Perhaps even more secure that the delegation (bearer) credentials
created by Grid users for batch applications.

What am I missing?

David




Archive powered by MHonArc 2.6.16.

Top of Page