limiting acceptance of entitlements (acls for unscoped attributes)

[Cantor, Scott]

On 9/23/11 6:32 PM, "Peter Schober" <peter.schober at univie.ac.at> wrote:
>
>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.

Note that 2.4 allows remote access to signed policy files. Not that it
helps you, but just thought I'd mention it. This was kind of the
motivation for that feature.

>Sadly I understand neither or those two paragraphs. How is the
>described use of entitlements static and what do other uses look like?

I didn't mean the entitlement itself was static or dynamic, I meant that I
don't have experience with using web server rules to do authorization. All
my experience is that it's inside application logic, or that you have
something intercepting logins, provisioning local data like groups based
on the entitlements, and then the app does its thing.

So I was saying what you were describing as two steps was for the cases
I'm used to sort of separate in terms of when it would get done and
sometimes who would do it.

>Ah, OK. I suppose forcing this through the attribute map (where it
>could then be configured) isn't an option?

It is an option, but I've avoided overloading the plugin that actually
uses the map. What I've been doing lately, and what I wish I had done with
all of that stuff, is to define new extractor plugins that are used to
pull specific assertion content out. I just did one for
AuthenticatingAuthority, and I did it with a new plugin that lets you
configure the attributeId, like I did with the Delegation thing earlier.

Maybe the thing to do is build a new one that encompasses the existing
"fixed" data I'm populating, have that in place by default using those
same attribute names, but otherwise treat them as generic attributes and
make the names technically fungible.

I'd have to think about the backward compatibility aspect, but it's
probably possible.

-- Scott