Franchise access being authenticated by our Shibboleth IdP

[Keith Hazelton]

On Feb 23, 2012, at 10:26, Keith Hazelton wrote:

> On Feb 23, 2012, at 10:15, Keith Carr wrote:
> 
>> 
>> 
>> On 23/02/12, Peter Schober <peter.schober at univie.ac.at> wrote:
>>> 
>>> * Keith Carr <kecarr at sgul.ac.uk> [2012-02-23 13:25]:
>>> > > No.  Don't try to imply entitlement.  The user either has it, or they
>>> > > don't.  So, go to the directory or database, look up entitlements.
>>> > > Done.
>>> > > 
>>> > I'm not sure I understand what you mean? What do you mean by look up
>>> > entitlements?
>>> 
>>> My interpretation would be to take that literally and lookup a users
>>> entitlements (e.g. common-lib-terms) from a directory service or an
>>> RDBMS and use those "as is" in the IdP. (Assuming access is granted to
>>> the SP based on an entitlement).
>> Ahhh, I understand. I do store the user's entitlement in LDAP (e.g; "student" or "staff") and this is supplied to the resource. I guess the answer would be to have a new entitlement given to the franchised users (e.g. "franchise") and to those resources that they have access, add it to the list of entitlements they accept?
>> -Keith
> 
> It would help this conversation if we could agree to use the terminology from the eduPerson specification:
> 
> student and staff etc. are affiliations.
> 
> common-lib-terms is an example entitlement
> 
> Here at UW-Madison we manage all this by associating a list of entitlements with an affiliation.  So "students" get entitlements to email, calendar, wiki, library, rec. sports, etc.
> 
> We "flatten" this in our LDAP and in our SAML assertions via business logic: That is, if Jane Swift is a student, then attributes in LDAP and/or SAML attribute assertions might include:
> 
> eduPersonGivenName: Jane
> eduPersonSurname: Swift
> 
> eduPersonScopedAffiliation: student

that should read eduPersonScopedAffiliation: student at wisc.edu

> 
> eduPersonEntitlement: email
> eduPersonEntitlement: calendar
> eduPersonEntitlement: wiki
> eduPersonEntitlement: library
> eduPersonEntitlement: recreationalSportsFacilities
> ...
> 
> How does that line up against your case?
> 
>        --Keith Hazelton (hazelton at wisc.edu)
> 
> 
>>> 
>>> 
>>> That's pretty close to what I said before when if I'd be creating
>>> such a system from scratch, to base it on the individual user(s).
>>> It'll also avoid implementing logic (and the inevitable exceptions) in
>>> the IdP, as all the logic (who gets access to what) needs to be
>>> implemented when storing those values somewhere in LDAP/an
>>> RDBMS. Granted it still has to happen somewhere, but then it'd be OOB
>>> and not involving the IDP at all. (Consider this "flattening" the
>>> affiliations, entitlements and "franchise" groups to a list of users
>>> and their services. Might also be useful for internally provided
>>> services).
>>> -peter
>>> --
>>> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>> --
>> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> 
> --
> 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/dc097b0e/attachment.html