limiting acceptance of entitlements (acls for unscoped attributes)

[Cantor, Scott]

On 9/23/11 4:14 PM, "Peter Schober" <peter.schober at univie.ac.at> wrote:

>Are people who are granting access to protected resources based on
>eduPersonEntitlement (or any other non-scoped attribute) also always
>preventing acceptance of this same entitlement value from issuers who
>are not part of a project/agreement/contract?

I don't use them often, but a couple of times I did, and I did add a
filter rule.

>If not, why do we bother with registering scopes in metadata and
>checking them on the SP?

I've made that statement too. But it is true that many more apps are just
identity and linked profiles, and the scope checks along with other
parallel features do prevent impersonation across IdPs in such cases.
That's more common than entitlement usage.

>Writing attribute-policy.xml instead and/or in addition to existing
>ACLs? Seems a bit error prone and tedious, with differing syntaxes
>for XMLAccessControl and attribute policies and two places to look and
>two files to maintain for access control?

To me, filter policies were expected to be centrally provided in many
cases based on the sources of entitlement minting. That hasn't played out
much.

But also, I never expected the primary use of entitlement to be in static
access control either. I don't really ever see static access control used,
so I'm not that familiar with the role of it.

I tend to think of it as one step (the filter rule) and then "app stuff"
that is separate from the SP.

>If the issuer's entityID were available as part of the built-in
>"aliases"[1] could one handle all of this in XML ACLs?

Depends on the rule, I guess.

>I know /allowing/ access based on entityID is considered bad practice
>(which I suppose is the reason the entityID is not made available) but

I'll freely admit that. I just don't think it's going to end well making
that possible, but if that's what people decide they want. Obviously
nothing stops the app from doing that itself, so making it slightly easier
isn't really a big difference.

What is, however, a problem is that I didn't reserve any additional names
for those rules. I can't just say "entityID now means XXX" because
somebody could have defined a rule like that. I'm pretty much stuck until
maybe 3.0 when I could claim breaking a configuration is allowable.

So it would end up being a more complex addition now, or waiting for a
simpler one later.

>Filtering out metadata for issuers from which the entitlement
>shouldn't be accepted seems a bit drastic and doesn't work in cases
>where the same Shib instance also protects resources that should be
>available to those entities.

Presumably you mean "the same application", since an app override can have
different metadata.

-- Scott