Franchise access being authenticated by our Shibboleth IdP

[Cantor, Scott]

>I agree, however I'm failing to see another way to accomplish the task I
>have been set.
>In an ideal world I'm guessing that I would set some values for
>eduPersonEntitlement indicating whether the user was allowed acces to the
>resource and agree these with the SP's?

Whether you call it an entitlement or something else, that's how you do
it. Whether you call it "affiliation=student" or "entitlement=foo", you
end up with the same outcome, the difference being that one is intended to
be calculated based on the user + service, and the other is not defined
that way.

Even if you force every entitlement in the world to be one value to avoid
having to argue over what the value should be, setting that per-service is
better than the alternative of misusing other attributes.

The problem with the anything-goes approach to attributes is that it
presupposes everybody working with some SP is willing to accept that. When
those of us already using some strategy for affiliation that meets the
intention of the attribute try and push back, the SP says "why are you
being so difficult, everybody else is fine with it".

There's also the fact that some sites have reasonable directories and
back-end systems, and they want to be able to store these attributes
directly rather than mocking them all up on the fly based on the service
identity. They can't do that if everybody devolves to using attributes
that don't allow for this.

>The problem I can see in this is getting all the SP's to organise and
>agree these within the time-frame.

You don't need to agree on anything more than what you're already
"agreeing" to for it to be at least a little less bad.

-- Scott