Franchise access being authenticated by our Shibboleth IdP

[Keith Carr]

On 23/02/12, Keith Hazelton  <hazelton at doit.wisc.edu> wrote:
> 
> 
> 
> 
> 
> 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?
> > 
> > 
> > 
> > 
> 
> 
> 
> 
> 
Hi (other) Keith,
That makes sense. Do you "flatten" the entitlements to one attribute value in ldap or one in each of a multi-vlaued attribute?

However in our case it's tricky. As I stated to Chad:-
"Franchise A" always have access to SP 1, SP 2 and SP 3 and nothing else.
"Franchise B" always have access to SP 1, SP 2 and SP 4 and nothing else.

So I would need to "share" a new entitlement with our SP's in order to differentiate the new franchise.

-Keith

> 
> 
> 
> 
> > 
> > 
> > 
> >        --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/95a8e9d5/attachment-0001.html