Roles vs Groups Rematch

DATE and TIME: Thurs. May 26 , 2011 11 am

CONVENER: Venu Alla, UC Berkeley

SCRIBE: Emily Eisbruch

# of ATTENDEES: 12

MAIN ISSUES DISCUSSED

What are roles and groups?

  • Chris:  A group is collection of subjects.
  • Example: A mailing list is a group, does not need to be a role.
  • A role is a collection of things the user can do, a way to confer permissions
  • Role such as "employees", boils down to the common set of things are that the members of the set can do
  • If you assign permanent permissions to a group, there is an implicit role.  A group is assigned to the role.
  • There is frequent confusion concerning the intersection of roles and affiliations
  • Relationship to a university (student, staff, etc), are sometimes called roles, but those are affiliations
  • Actually the role should be a generic thing such as "approve expenditures up to x amount"
  • Non-techies think a role is a collection of responsibilities people have. Thinking of a role as a set of permissions is a more techie approach, an approach that does not make sense to all people
  • Arnie: need to differentiate between job and responsibility
  • There is a problem /gap if we see everything as a group or a role.  There are also entitlements. There are things you can do if you want to, you are entitled to do, but are not responsibility.  Sometimes, but not always, these involve permissions.
  • Omer: OpernRegistry looks at roles as connected to affiliation.

Deprovisioing Issues

  • If access control is based on implicit roles, and then someone gets fired, it's hard to adjust in a central way unless you have good deprovisioning
  • If there are implicit permissions with "staff" and you get fired,  then the role gets removed and all your permissions go away
  • Which permissions should actually go away when your role ends is related to business policy. How to reflect the business policy?
  • Can handle some of that at the authentication level
  • Deprovisioning permissions is the biggest issue at Brown. Use of Grouper is helping in some cases.

What are best practices?

  • When to roll something into a role?
  • When to call something a group?
  • In Grouper, you can assign a group a role.
  • In Grouper, any path you have that assigns you to the role is OK. If you have 3 paths to a role and one goes away, you still have the role.
  • In Grouper, roles are for applications. An application can have a student role.
  • There could be a role of payroll clerk. But an app should not have more than 5? roles
  • Not recommended to have a role of English Dept nor a role of History Student
  • Just have a role of Student
  • Then have individual permissions such as "history"
  • But what if a student changes major?  Would be nice if you did not need manual intervention. Would be nice if  -- when changing majors -- you change groups and that is all that's needed.
  • UC Berkeley -- setting up layered roles business roles  and also setting up appl roles (calendaring, etc).  This is like the Sun IdM definition of roles.
  • Another layer of roles besides student, faculty, staff. There is institutional or business role, e.g. payroll processor.

Working Towards a Common Understanding of Roles

  • If we can have a common understanding of roles it will help. Could there be a common template for role engineering, across all campuses? Hard to  get there.
  • Maybe we could have a standard framework for defining roles.
  • Stakeholders ask, "can't you assign permissions to a job classification? " Answer is NO , can't assign permissions to a job title
  • Goal is to get a standard framework.  Normalize roles.  
  • Could the I2 space have a common section on role engineering
  • UC Berkeley starting to look at a framework for institution-wide roles. UCSD did this previously.
  • At UC Berkeley, looking at applications, going from bottom up
  • What is the driver for developing institutional roles and centralized access based on them?
  • At Penn State, there is a directive from the top to work on access management and there is a lot of buy-in

Problem defining roles

  • If a role is a collection of permissions, then it follows that roles can come and go, and what they mean can come and go at different points in times, you have different permissions
  • Yes, you can change permissions in a role, but the role can still exist
  • The business rules attached to the role can change
  • If you say, "we are not going to allow students access to this anymore," is it the same role?  Assumimng that the role is the collection of permissions, then if you change that set of permissions, does the role go away? No! so a role cannot be a collection of permissions
  • There are roles and business rules. The role is an abstraction the institution finds useful for collecting behaviors
  • Arnie : A role is a set of responsibilities and entitlements, and maybe it has nothing to do with permissions,  Maybe a role is what you are in the world. 

Groups are More Transient Than Roles?

  • At UC Berkeley, use groups (not roles) when it's short-lived or more dynamic
  • Student exists thru life of campus
  • But a class that the student enrolls in come in as a group and then goes away
  • A wiki has a user account and an admin account that last
  • Can form groups for a wiki to collaborate on  a project ---- that's a dynamic group, it comes and goes
  • Mutations in roles are slow
  • The bulk of what it means to be a student does not change, but groups can be fast to mutate

-
Q: Is there something in Grouper where I can convey my business logic, what a user is entitled to do, so I can allow people to access certain things?

A: Chris: In Grouper, roles have permissions. Whatever you want to protect, you can assign to roles, or users in roles. The  end result is that when the application runs, you say what this user has access to.

Q: Assert attributes in Shib. It's course-grained, either on and off. But need fine grained. Can Grouper provide that?

A: Chris: need to look at each case and the application that is consuming the permissions

-
ACTIVITIES GOING FORWARD / NEXT STEPS

  • Finding a common space where we can throw up doc from campuses that have done significant role engineering
  • Campuses using Grouper should share how they are establishing/defining groups vs roles, and push towards a common ground

-
-
-
If slides are used in the session, please ask presenters to convert their slides to PDF and email them to SteveO@internet2.edu

Thank you!

  • No labels