Shibboleth Developers

[Frank Siebenlist <>]

Sorry for chiming in a little late on this topic, but I still have a few 
questions.

I've copied some snippets from this long thread at the bottom for 
reference, but I'll try here to explain the issue we have at hand in my 
own words.

As I understand it, we have two separate use cases

1) a client contacts a service provider (SP), and the latter will ask 
the client's attribute authority (AA) for the set of attributes it can 
reveal about that client.

2) a client first asks its AA for the set of attributes associated with 
itself that the AA would reveal to a certain SP, and subsequently the 
client would present that set of attributes to the SP with its service 
invocation.

In both cases, the SP and the client "pull" attributes from the AA, but 
we normally refer to the second use case as "push" as the client will 
push the attributes to the SP.

Note that our "push" model is often driven by firewall considerations 
where the SP is unable to contact the client's AA directly because of 
firewall hurdles. The client lives within the same administrative domain 
as its AA and doesn't have that issue. It's interesting that Scott comes 
in from a different angle in that respect.

Now, the attribute request is this saml attribute query with a Resource 
attribute and a Subject element.
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".
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 (?).

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.

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.
The only difference would be that now the client is the requester 
instead of the SP, and that the AA should make the access control policy 
check whether the requester is the same as the subject mentioned in the 
query.

I agree that we shouldn't bother trying to define the AA's access 
control policies to allow anyone to ask for attributes for anybody else, 
but the access control policies for the resource and the subject 
mentioned in a attribute query seem easy to generalize and we have two 
real-world use cases that could benefit from this.

An other important difference is that when the client pulls the 
attribute set for an SP from the AA, she (and the SP) wants the AA to 
sign the result to provide the SP with the integrity proof of the 
attribute set.
The idea of pushing the ARP-filtering back to the client could result in 
the same set of attributes, but now the AA can not sign this filtered 
set anymore.

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

Regards, Frank.

PS. Sorry if I didn't use the right jargon and nomenclature as I'm still 
learning the Shib-speak...







------------ <snippets>--------------------------

> The security model is such that I don't think we want to complicate matters
> by talking about people asking on behalf of something else. Nor is there any
> place to put the service's providerId. Not even in SAML 2.0. It makes more
> sense to me that the client would figure out what it needed using the same
> mechanism the AA would have to have.
>  
...

> There are some serious firewall implications for clients talking to an AA, I
> would guess. Lionshare is fine and all, but it's hardly going to drive open
> access to AAs anytime soon. I don't personally have mine firewalled off, but
> I could easily imagine other people might and would be upset about having to
> open access to the entire Internet instead of specific SPs.
>  
...

> > Essentially, what we'd like to do is communicate attribute
> > requirements to the AA by reference (not by value).  Since the AA
> > already knows the attribute requirements of the grid service (via
> > ARP), we were hoping to capitalize on that in some way.  Any ideas?
>  
>
>
> Well, in 1.1, you could use Resource for this, assuming you identify the
> requester some other way (I'm so glad there was no "use case" for Request
> Issuer when I argued for it three years ago. sigh).
>
> In 2.0, it's kind of impossible without an extension. This particular use
> case wasn't on the table, and Resource didn't have a well-defined purpose
> once Issuer was added.
>  
...

> I thought the AA keyed off Resource to distinguish queries.  Correct
> > me if I'm wrong, but Resource is usually the SP providerId.  In the
> > case where a user is asking for its own attributes, I thought Resource
> > was a static value indicating the client type (e.g., LionShare).
>  
>
>
> We define Resource to be "requester". Issuer for all intents and purposes.
> Since that only accomodates system entity names and not generally people at
> the moment (maybe XRIs will change all that), the LionShare plan was to
> avoid overloading it and use a fixed value or just omit it and use an HTTP
> header, I don't really remember what was decided.
>
> Ironically, though, using it as "the context in which the attributes are to
> be used" is more like the original intent of the attribute, and is a pretty
> close fit to what you're describing.
>  
------------ </snippets>--------------------------


--
Frank Siebenlist               

The Globus Alliance - Argonne National Laboratory