Franchise access being authenticated by our Shibboleth IdP

[Keith Hazelton]

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120223/04b47fd6/attachment.html