limiting acceptance of entitlements (acls for unscoped attributes)

Peter Schober peter.schober at
Fri Sep 23 21:14:23 BST 2011

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?

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

If so, by what means do you prevent the acceptance of such attributes?

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?
If the issuer's entityID were available as part of the built-in
"aliases"[1] could one handle all of this in XML ACLs?
I know /allowing/ access based on entityID is considered bad practice
(which I suppose is the reason the entityID is not made available) but
this also prevents /denying/ access based on that info.
How else then to prevent any IdP known to an SP via metadata (which
might be many, once con-/interfederation arrives) to issue

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.

If you don't prevent acceptance from any IdP do you monitor your log
files to even detect the case? Since attribute values aren't even
logged how would you do this?



More information about the users mailing list