limiting acceptance of entitlements (acls for unscoped attributes)

[Peter Schober]

Thanks for the quick and thorough anwser.

* Cantor, Scott <cantor.2 at osu.edu> [2011-09-23 22:43]:
> 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.

OK.

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

Certainly. Didn't consider about ePPN and individual impersonation,
that might be a lot more serious than affiliations.

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

Sure, I was planning on supplying those rules as well, I just wanted
to make it as easy as possible for the SPs to implement so that it
would actually happen. And with some of the SPs being still on 2.3
(Debian, security fixes backported) which means I can't just send them
an additional policy file and have them include it in shibboleth2.xml
with a single line. Instead they will have to edit the existing file,
inserting rules in the right place, etc. and not fsck it up in the
process. But as long as I can be pretty sure I'm the only one sending
policy rules maybe I'll just send a complete copy of
attribute-policy.xml including my changes.

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

Sadly I understand neither or those two paragraphs. How is the
described use of entitlements static and what do other uses look like?
Assignment could be dynamic based on other data and my current rules
contain regexes to they are pretty flexible, but still static, of
course.
How should one supply filter/policy rules for "dynamic" entitlement
use?

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

Enumerating (<OR>) accepted IdPs <AND> a specific entitlement value?

Enumerating IdPs not in a position to release the entitlement is of
course pointless, since new IdPs will never be listed in time at each
SP and interfederation makes a list of unauthorized IdPs absurd.

Here's an example not quite unlike something I had to use before,
except of course for the made-up entityID attribute rule:

  <AccessControl>
    <OR>
      <AND>
        <RuleRegex require="affiliation" ignoreCase="true">^(student|staff|faculty|member)@(a\.edu|b\.edu|c\.edu)$</RuleRegex>
        <RuleRegex require="mail">^.+ at .+$</RuleRegex>
      </AND>
      <AND>
        <RuleRegex require="entitlement">https://foo.example.org</RuleRegex>
        <RuleRegex require="entityID">https://example.com/idp/shibboleth</RuleRegex>
      </AND>
      <Rule require="eppn">some at example.com special at example.com userids at example.com</Rule>
    </OR>
  </AccessControl>

Most users would be accepted based on their affiliation with selected
institutions, with some users being accepted based on their userid
(e.g. test accounts for the SP, so institutions providing the test
accounts to/for the SP wouldn't have to lie and make those test
accounts member at x.edu when in fact they're not). And then there's the
IdP (would be several, of course), where only specifically vetted
principals would be assigend an agreed upon entitlement (and the
population of that IdP or the meaning to be communicated does not fit
the controlled vocabulary of eduPersonAffiliation).

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

That would also be true for the opposite (check the assertion in the
application and throw away offending attributes), I suppose, but of
course I'm trying to make it /easier/ for SPs.
I tried to prevent misuse of nonsensical scoped affiliations as
suggested (and implemented) by some. If access contol now becomes an
application issue (which atm is solely handled through shib config) I
actually did the app owners a disservice by trying to hold up
standards and BCPs.

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

Ah, OK. I suppose forcing this through the attribute map (where it
could then be configured) isn't an option? Not that I'm convinced
having it available in access control rules will drastically simplify
the problem of "Доверя́й, но проверя́й" (trust, but verify) I have with
unscoped attribute values.

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

No, I was mistakenly assuming they shared metadata providers.
Thanks for pointing it out. Doesn't change my point about metadata
filtering probably not being the proper way to do this, though (not
that you implied such).
-peter