Shibboleth Developers

["Scott Cantor" <>]

> Now, the attribute request is this saml attribute query with a Resource 
> attribute and a Subject element.

SAML 2.0 has no Resource attribute. Thus, relying on it is problematic.

> I very much understood the Resource to have the semantical meaning of 
> "the context in which the attributes are to be used" or "the one that will
> consume the attributes".

It meant very little because only Shibboleth pushed for it and tried to use
it, and we ended up needing request Issuer a lot more. So we made it that. I
wanted Issuer to begin with, but I didn't get it until 2.0.

> I thought this was very different from the requester, which is the 
> (authenticated) entity sending the query. As the request is authenticated,
> the "requester" should be known within the context of the received query,
> which would indicate that we wouldn't need to add a Resource to the query
> itself (?).

Without an Issuer field, authentication becomes more complex and naming
becomes technology dependent. Issuer allows policy to be set in terms of
SAML entities and a single credential to be authorized for use by many
authenticated entities because the requester name is known outside of the
authentication process. It creates an abstraction between the physical
credential and the logical requester.

This is important because we (speaking of Shibboleth) don't use PKI for
naming, and we didn't want any policies expressed in terms of certificates
(or any other technology).

If you start out by setting policy in terms of physical authentication
tokens like certs, then it makes little sense to add an Issuer on top of
that, you're right.

> My understanding of the code (thanks Tom!) is that the AA will make a 
> separate access control decision whether the requester is allowed to see 
> the query results, by ensuring that the requester is mapped to the 
> resource in the SP-metadata. In my view this was a very different 
> "conceptual" step from the collecting and SP-filtering of the 
> requested attributes through the ARP.

Right now, AA policy is based on exactly one thing, the requesting SP. The
Lionshare use case was "short circuit all ARP processing and allow a
principal to request any and all attributes it wants about itself". In
neither case is the eventual consumer of the attributes mentioned, except
that it's somewhat implicit in the Shib case because we don't profile
forwarding of attributes.

Metadata is used to determine whether the physical credential is authorized
for use by the requester. In Shibboleth, the Resource attribute is the key
for this lookup step (because we had nothing else to use), and then the
credential is validated against the keys allowed for that requester.

> The advantage of my (possibly distorted) view is that if the subject 
> that is mentioned in the attribute query is allowed to see all her 
> attributes, then we could have the client use an query to obtain the 
> attributes for a SP from the AA that is identical to the query that the 
> SP would send to the AA: same resource=SP.

You could do that, it's just not the current profile, and more importantly
is not physically doable in 2.0. Sorry, but nobody argued for keeping
Resource because the only people using it (us) were really treating it as
Issuer because there was no place else to put it.

> Any advise or suggestions how to "solve" our push use case would be 
> greatly appreciated.

As I said to Tom, I believe that any query should simply articulate what it
wants, and there is no big need to be able to say "I want the set for SP
Foo". If you think the AA has a basis to know what the SP wants, I see no
reason why the client can't know.

As I understand it, that was the intent for Lionshare. The user is the one
who knows what he/she is willing to give to the SP (in that case the peer),
and the Lionshare model is such that the list of desired attributes is given
to the client in the course of dialog with the peer because it may depend on
the resource being accessed.

Here, it seems like the model is more like the usual Shib SP, where a fairly
coarse grained service desires a relatively fixed set of attributes that it
could publish in its metadata. Client reads metadata, prompts user to obtain
permission to release attribute set, then queries AA for them.

I don't see any other way to do this in 2.0 unless you extend the query
syntax.

-- Scott