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:
  • Subject: Re: Fwd: More detailed Grid scenarios
  • Date: Thu, 15 Jan 2004 09:37:53 -0800

Hmm... deja vue all over again.
-----
At 10:48 AM -0600 on 1/15/04, Von Welch wrote:


> This model assumes, in Shibboleth terms, that the user's Origin
> Domain is the domain of the target service (step 1 above). The twist
> is that the Origin Domain is not authoritative for at least some of
> the attributes of interest.

No, just that the target service accepts identity credentials from the
user's origin domain (e.g. it trusts the CA that issued the user's
EEC).

But this is exactly the problem that Shib was invented to solve: inter-domain inter-operable credentials are hard. Instead, let the user's "home" domain understand the credentials and then provide authoritative information about the subject to the target. That's the function of Shib.

> From a Shib point of view, the "target" in this case wants to be able
> to ask a particular AA at any point in time to release information
> about some entity. There is an assumption that the target has an
> identifier of some sort for the subject that is recognized at the AA
> -- the cert Subject Name may or may not be that identifier, depending
> on how it was created. So the subject identifier is the first
> problem. (+)
>
> The second problem is simpler: a different API to the AA. This would
> be a simple query interface where the asker is identified by means of
> a trusted cert (no mean feat but that's another story). As with any
> query to the AA, there is default information that it will release to
> any asker but if the asker is "known" to the AA, then it may have a
> specific ARP to apply to the query. Again the crux is the identifier
> by which the asker seeks to be recognized.

Right. I think we've had discussions in the past if Shib could use a
Subject name instead of a handle. The answer I believe I've gotten is
"yes with some work".

OK - I was not going to raise this but I guess I need to: what is in the SubjectName field of a user's "home" campus cert may or may not be useful in a query to the "home" AA. And if it is, what part of it?

For example, the UC certificate profile defined SubjectName as
C="US"
O="University of California"
OU="<campus name>" e.g. "Berkeley campus"
CN="<UC NetID>" which is a large integer unique to the individual

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.

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.

Just want to make sure this assumption is on the table.

David




Archive powered by MHonArc 2.6.16.

Top of Page