Shibboleth Developers

[Scott Cantor <>]

> One thing we need to decide initially is whether the target
> will use this same document to make authorization decisions.
> If not, much of the information will have to be duplicated,
> and the information available to the arp gui will be
> unnecessarily limited, so I suggest that we do use it.

I think that's ultimately going to be a mistake. Authorization is really,
really complex, and I think is best left separate from a basic expression of
"what I want you to send me", which is the only thing the contract
represents.

Yes, it's duplication in some ways, but if it really matters, then one can
always generate both out of the same source of data.

> Below are some samples of an xml syntax that seems to me to
> cover the basic requirements. Each <AccessPolicy> would be
> associated with an application and one or more identity
> providers in shibboleth.xml.

I think access policy has to go way beyond the application level down to the
document level. Put another way, the application is just a unit of session
management, not an authorization boundary. This assumes static access
control is viable at all, which is not true in my experience except for the
case of documents. And in such a case, the policy often varies by document,
which is why web servers enforce rules down to that level, and I think we
have to honor that requirement if we're going say "don't use htaccess, use
this instead".

Because I felt this way, I made a very specific decision to put the
extension point for the AccessControlProvider element inside the RequestMap
element, and not in the Application element. Not that it couldn't be
changed, but I'd have to be convinced how that could be sufficient.

-- Scott