Franchise access being authenticated by our Shibboleth IdP

[Keith Carr]

On 23/02/12, Chad La Joie  <lajoie at itumi.biz> wrote:
> On Thu, Feb 23, 2012 at 07:24, Keith Carr <kecarr at sgul.ac.uk> wrote:
> > I'm not sure I understand what you mean? What do you mean by look up
> > entitlements?
> 
> I don't know how to say it any differently.  Go to your datasource,
> execute a query for entitlements/privileges/grants (whatever you want
> to call it), get a result back.
> 
I get you now. We do store entitlements in LDAP and use that normally.
Am I right in thinking that because the user from the franchise has the right to access SP 1 like one of our "normal" users but not SP 2 (when a normal user still can) we would have to create a new entitlement value to share with the SP's? Otherwise both SP's would understand the user from the franchise to have the same right to access as a standard user.
Otherwise how can you determine the entitlements for a person for a resource?

> 
> 
> > Surely this isn't fuzzy logic?
> > -Look up the user's group
> > -Determine if the group has access to the resource requested
> > if (the group has access to the resource) {
> >   give permitted value to the user's eduPersonAffiliation attribute
> > } else {
> >   do not give a value to the user's eduPersonAffiliation attribute
> >
> > }
> 
> Let me give you a real world example that I've seen play out a dozen times.
> 
> A university has a student learning system (lets say its Blackboard).
> They then use the following logic to imply entitlements in the system:
> - anyone who is a faculty and associated with the class gets the
> "teacher" privileges
> - anyone who is a student and associated with the class gets the
> "student" privileges
> 
> The first day of class comes and we have these issues:
> - the teacher assistent finds out that she can't view the roster for
> the class because she's not a faculty member and therefore doesn't
> meet the logic used to determine she should have "teacher" privileges
> - a students who can't view the class at all because the registrar
> hasn't processed their last-minute request to join the class
> - a faculty member signed up to take this course, as a student, and
> suddenly has access to all the "teacher" information because they're a
> faculty member
> 
> These exceptions continue to show up and the "logic" used to determine
> who is a "teacher" and who is a "student" grows until its meaningless.
> 
> > Can you explain (in a simple way) how you would achieve what I am trying to
> > accomplish?
> 
> Don't say "Person X has a right to SP 1 because they're in franchise
> A".  Instead say "Person X has a right to SP 1" and record that in
> your LDAP or database.  Then, if down the road, Person Y should also
> have access to SP 1 (regardless of the franchise they are a member
> of), you simply record that as well.
> 
> Let me also note one thing.  Some of this confusion may simply be
> semantic.  If "franchise A", to you, means "a group of people who
> always have access to SP 1" and absolutely nothing else, then what
> you're doing is fine.  Most people would normally call such a group a
> "role" or a "permission group" but there is no set terminology.
> 
> Problems arise though when "franchise A" means a bunch of different
> things, e.g., "a group of people who always have access to SP 1" and
> "a group of people who always have access to SP 3" and "a group of
> people who never have access to SP 3".  Some person, at some point in
> time, will likely come along that violates your set of rules and then
> you're going to be in a tough spot.
> 
I would mean to say:-
"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.

-Keith

> 
> 
> -- 
> Chad La Joie
> www.itumi.biz
> trusted identities, delivered
> --
> 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/f28162ee/attachment.html