Franchise access being authenticated by our Shibboleth IdP

[Keith Carr]

On 23/02/12, "Cantor, Scott"  <cantor.2 at osu.edu> wrote:
> On 2/22/12 8:40 PM, "Chad La Joie" <lajoie at itumi.biz> wrote:
> 
> >Decide locally how you're going to store grant information for any
> >random service.  I'm an LDAP kinda guy so I'd do it there.  Scott's a
> >database guy so he'd do it there.  But wherever you do it, just be
> >clear that what you're doing is store a grant to a particular service
> >because a specific user has access to that service.  Don't try to
> >infer it from some other potentially correlated data.
> 
> I didn't see his proposed approach as anything other than this. But the
> issue for me is what the attributes are on the wire, because that's what
> determines whether you're re-doing your resolver every time you federate
> with an SP. My goal is not to do that. Really, it's more like a
> requirement, given the risks.
> 
I was just hoping (by finding the user's "franchise group" in ldap and then using this to look up whether that franchise group had access to the resource being requested in the database) to simply supply one of the standard permitted values for eduPersonAffiliation (if they are entitled to access) to say "this person is permitted to access the resource" to the SP. If they are found not to be entitled to access to the requested resource then the value to the eduPersonAffiliation attribute would be left blank and therefore rejected by the SP.
I was hoping not to have to keep changing the attribute I use to say to an SP whether the person is entitled to use it or not on-the-fly so to speak.

-Keith

> 
> 
> >Once you get that, then you can talk with each SP to see what
> >attribute they want you to send and what value they want.  You can use
> >the IdP to lookup the data, name it whatever the SP wants, munge the
> >value to whatever they want, and send int.
> 
> You certainly can do it that way. But I don't want to, and more
> importantly in the context of this thread, I don't like to see practices
> from others take root that will end up forcing me to do what I don't want
> to do when it's my turn. This is all Mutually Assured Destruction at the
> end of the day.
> 
> -- 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/e250edf7/attachment-0001.html