Franchise access being authenticated by our Shibboleth IdP

[Chad La Joie]

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.

> 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.

-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered