Shibboleth Developers

["Scott Cantor" <>]

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

Whose policy? The SP wants what it wants. The user will or won't be willing
to release that information. I don't see the need for an ARP at all with
push, just a UI to say "here's what I'm going to get and send if you don't
stop me..."

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

In the pull case, this is already an issue, same as now. We simply haven't
spent any time on this. All the use cases now focus on administrative
release of the data.

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

That's why we haven't done it. But I would say that the approach should be
to maintain policy completely outside this code base, and just build an ARP
engine plugin that retrieves them from that store. There should not be a
service interface. There's no need to couple things tightly.

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

Client pull (what I call push) means no ARP (at least so far). SP pull is
where you have ARPs. And I disagree that having the policy in the AA is
desirable. It's necessary in some cases, but if it's the user's policy, it
belongs with the user. It only has to migrate away if the user doesn't get
to actually intervene in the transaction.

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

It is for Lionshare as well. And you can. Just ask the AA for what you want.
I don't understand why that presents a problem. You want to rely on the AA
to know what to release, when in reality that's the most awkward part of the
whole thing, setting up ARPs out of band, currently with no UI to do it.
It's like writing a database application with nothing but stored procedures
but you don't have easy access to the database.

Here, you don't have the problem, you can do it all kinds of ways because
you have a user interface. You could post a metadata file at the SP, the
client could grab it, present the list for permission, etc. That's merely
*one* way, I could think of many.

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

I can't deny that queries do not have the ability to tailor the assertions
they get. For example, you'd also ideally like the SP to be in the audience
list, but there's no way to ask for that (or any other condition) either.

But I'm not convinced that an extension is needed in this particular case. I
don't see how the pull model breaks simply because the client has to specify
attributes in its query.

> Aren't there extensibility attributes/elements in the interface that 
> would allow us to do so?

Yes, there are (in 2.0 anyway).

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

Well, we haven't done 2.0 yet anyway. But it also means commercial products
won't support you.

-- Scott