Franchise access being authenticated by our Shibboleth IdP

[Keith Carr]

On 23/02/12, "Cantor, Scott"  <cantor.2 at osu.edu> wrote:
> >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.
> 
I'm not sure what you mean here, can you explain further in layman's terms?

> 
> 
> 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".
> 
Yes, I'd rather use something standards-based so it's easier to maintain in the long run.

Thanks for your help with this,
-Keith

> 
> 
> 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
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120223/61ffff9d/attachment.html