Shibboleth Developers

[Frank Siebenlist <>]

Ok, so we won't have any more Resource or "AttributeConsumer" directive 
in the standard SAML-2...

Now, whether the client asks for all the attributes, or first asks the 
SP which one it needs, or whether there is SP-metadata at the AA that 
works as the SP's default set doesn't seem so important - we'll work 
something out.

I'm more concerned about the idea that each client will have to do its 
own ARP-filtering for the SP it wants to push the attributes to.

I can see that many deployments will have multiple client machines from 
where a user can work. Also in our Grid deployments, there will be many 
intermediates that will work on behalf of many users. Furthermore, in 
many cases you want to store your policies centrally.

In other words, the user's ARPs will be need to be found/discovered in 
real-time, they have to be retrieved through a standardized interface, 
the format of the ARP as an expression language will have to be 
standardized, and matched with an associated ARP-filter engine. If the 
ARPs are maintained somewhere outside the Shib-AA, then the user will 
have to upload them through another standardized service interface. We 
will have the issues of syncing the different places where those ARPs 
are used. So, each AA should probably have service interfaces to 
retrieve and upload the user's ARPs.
This is all non-trivial stuff!

On the other hand, all the ARP-machinery is already centrally integrated 
in the AA (with wonderful ARP-admin tools coming soon ;-) ), the ARPs 
and associated filtering is right there at the attribute source where it 
should be, the required processing model for a client-pull is well 
understood, and the required changes to support client-pull are all 
locally to the AA and shouldn't affect anything else...

I'd also like to reemphasize that the client pulling attributes from an 
AA for a specific SP is a real requirements for us.

Would it be possible to consider the option to add this Resource or 
"AttributeConsumer" directive to the standard SAML-2 query interface to 
accommodate our use case?

Aren't there extensibility attributes/elements in the interface that 
would allow us to do so?
(the infamous void* for xml )

This would essentially mean an additional new interface to the AA in 
order to accomodate this particular client-pull mode.

-Frank.




Scott Cantor wrote:

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

--
Frank Siebenlist               

The Globus Alliance - Argonne National Laboratory