Shibboleth Developers

[Scott Cantor <>]

> By "simple query API" I mean as opposed to the complexity of the 
> "handle" interface where there are a lot of checks, etc., to avoid 
> malicious user behaviors.

Hmm, maybe you think we do more checking than we do...;-) If you know a
handle and it's valid, the request is accepted. An example of something we
could do with some extensions that Walter and I have talked about is to
encode the target of the original assertion so that only that requester
could use the handle. We don't currently put enough in the protocol flow to
the HS to do this easily, but we want to.

> Yes - what I am describing is a lot like a database query but not 
> nearly as complex.  No following DITs or conditionals; just "here's 
> an identifier - what can you tell me."

Right, that's what it can do today.

> The advantage and value that 
> the AA brings as a front end to the enterprise directory is precisely 
> in the ARP capability.  It can provide a much more policy-driven way 
> to decide what entity can get what data.  And - it can take into 
> account the subjects preferences as well (as you know).  So - that's 
> why I've always said that the AA is the most important piece of Shib.

And granted there's no reason LDAP can't support this kind of thing in terms
of access control.

> What I was getting at is that the "origin" (which is also the 
> "target" in this case) doesn't even have the data - it is going to go 
> to a third party to get it.  Not that this is awful, just a twist.

Well, there's the question of how you get the data and how you express it.
I'm saying the former is irrelevant, and the latter is at least possible to
defer to a set of policies that simply grant an AA permission to tell you
something.

Expressing the actual indirection between the assertion issuer and the
attribute's "owner" is and remains a topic being discussed by SAML and XACML
and reaching fairly limited consensus so far, as Von can tell you.

> See my comments at the beginning.  The issue is really: what set of 
> identifiers is the AA interface able to accept?  For example, if the 
> app queries on the human name, e.g. "John Smith", and there are 9 of 
> them in the AA's database, is the AA prepared to return an 
> appropriate error message?

That's up to the attribute resolver, ultimately. If the particular attribute
in question should only have a single occurrence, one can enforce that. If
not, that's fine too. This varies somewhat in how its reflected in the LDAP
case vs. JDBC, and so on.

> In the example Von gives "the user authenticates to the target" so 
> whatever identifier the GRID target has for that user somehow needs 
> to be understood by the user's home campus AA.  That's why I 
> suggested that the GRID use the home campus EPPN as their identifier 
> for GRID members.  It will work nicely in a query to the home campus 
> AA.

Sure, there are any number of choices that make sense, but EPPN is at least
somewhat accepted. DNs are fine if that's prevalent at a campus...

> It is certainly simpler to assume that it's OK for a query to the AA 
> to occur at any time for any entity.  The ARP should protect the data 
> appropriately in most cases, I think.  The one obvious problem is 
> just what occurs today with campus "phone book" directories - 
> harvesting.  I think the only mitigation for that is to recognize 
> that sort of anomalous behavior and Do The Right Thing.

Well, I think we can do a bit better than that, but we're still discussing.

-- Scott