“All the world’s a stage,
And all the men and women merely players;
They have their exits and their entrances;
And one man in his time plays many parts,
-Shakespeare, As You Like it
A case study to illustrate multi-role RBAC engineering design
There are many challenges in defining roles within an enterprise, but I think trying to define the role of a grad student poses unique challenges and points out some of the shortcomings in role definition organizations run into when they try to simplify the role definition process.
We just finished a review with one of our higher education clients who has implemented a first try at role definition across the university. They did a good job, can count on many successes, but some of the early role decisions are coming back to bite them. Thought sharing the challenge of the grad student should help illustrate some of the basics of role design and engineering.
So first, the challenge.
The university wanted to implement a Role Based Access Control (RBAC) scheme where everyone was going to be assigned a role to gain access to different university resources on the network. The decision that is coming back to bite them is, in order to simplify the role engineering and the administration of those roles, every user on the school’s network was to have only one role and one minor role. If you were a student, you were assigned the role of STUDENT and that created an email box, home directory, home printer, etc. across the variety of platforms on the university network. Professors and teachers (Role::FACULTY) got pretty much the same access (email, home directory, etc.) but also to the grading system and online research repositories.
Access to specific systems, like Chem Lab servers, were created as separate roles from the basic STUDENT/FACULTY roles and could be assigned as well as a minor role. The University developed this second level of roles to help gain some finer granularity around system entitlements, but it meant these secondary roles had to be mutually exclusive of the entitlements set covered under the STUDENT/FACULTY roles. Everyone could have two roles that did not conflict with each other. A student could be a STUDENT and a CHEMISTRY major and get access to almost all of the systems they needed on campus. A simple role design (major role and minor role) that was simple to create and administer.
This approach greatly simplified the management of roles (still, lots of spreadsheets, emails, phone calls, and home grown databases), but it breaks down when it comes to the grad student.
STUDENTs had been migrated over to Google mail accounts, but FACULTY still had an internal Sun mail server, due to in part to the confidential nature of some of the faculty’s research. Every time you switched from STUDENT to FACULTY or back again, the user had to switch mail servers and in boxes, disrupting their work spaces and their work. A side effect of this was the explosion of minor roles, where roles were created almost as one-offs to get around the limitations of this two role approach. Administration did not go down with this two role design, it actually increased, as new roles had to be created and approved to get everyone proper access to the university’s resources. Thus the call for a review by our identity team.
Pity the poor graduate student. They are students, yes, but most of them also act as teacher assistants, so that makes them faculty as well. In this particular University, many of the faculty are taking graduate courses as well, so that makes a FACULTY member a STUDENT as well. Many students become grad students and then become teachers. With this rigid major/minor role approach, the poor grad students were getting thrashed when gaining access to basic university resources.
A grad student:
- Is a student, so should have access to student resources
- A graduate student, who may need additional privileges as a graduate student
- An employee, who needs to pay tuition and receive a paycheck for teaching
- A research assistant who may need access across departments to support research work for the university
- May work on external projects with corporations or government based research
- Eventually, become an alumni and need residual access to the school the know and love
So, as Shakespeare pointed out centuries ago, a role management system has to handle the changes a user might go through during their relationship with the university. This points out the need to adopt a more sophisticated, multi-tiered, multi node hierarchical role structure. Roles should contain entitlements specific for the individual and access to resources needs to be on a highest privilege (versus the more traditional least privileged) assignment scheme. As a student, the user should get access to the grading system to see their posted grades, but as a member of the faculty, they should also get access to the grading system to enter grades from the classes they teach in, something an average student is not entitled to do. But not to change their own grades.
So a much better approach to role design is to get more sophisticated. Users should get assigned roles they need and these roles assessed as a whole group to determine highest privilege access to the various systems and to check for separation of duty (SOD) conflicts. A grad student should have the role of STUDENT, the role of FACULTY and additional roles, like CHEMISTRY DEPARTMENT and RESEARCHER, that are evaluated as a group to determine the final access to the university systems. Roles don’t explode, because the current set of roles are evaluated as a group and a blended entitlement set is determined for the user.
And this approach allows for more flexibility without complexity. Access to sports facilities can be added as a separate “line item” role, controlling who has access to the sports facilities around campus. And a good role management system allows for individual “tweaks”, such as giving a chem student access to the lemur research cages just because they want to help a friend at night. Additional roles do not have to be created for these one off scenarios.
Role management software is available today to help better engineer and design these blended roles and to evaluate final entitlement sets. They can even be integrated into provisioning systems to automatically set account access for the user.
So, look at your current approach to role design and see if it can pass the Grad Student Test. If there are built in limitations that would not support the entitlements assignment of a graduate student, you might have a time bomb waiting to go off sometime in the future. If not, might be time to go back and rethink the approach to roles being used in your organization.
