6
votes

I am trying to understand access control based on RBAC model. I referred to the following link.

NIST RBAC Data Model

I haven't understood this part clearly as mentioned in the excerpt -

*"Each session is a mapping of one user to possibly many roles, i.e., a user establishes a session during which the user activates some subset of roles that he or she is assigned. Each session is associated with a single user and each user is associated with one or more sessions. The function session_roles gives us the roles activated by the session and the function user_sessions gives us the set of sessions that are associated with a user. The permissions available to the user are the permissions assigned to the roles that are activated across all the user.s sessions."*

Question - How can session be used to activate roles ? The relationship between the user / group and roles are inserted as admin data. So, how does session activate subset of roles for a user ?

P.S -> I asked this question earlier here but without an answer. May be this question is too basic to ask but I am keen to understand it. Any use case or a link will definitely be helpful.

Thanks for your time.

2

2 Answers

5
votes

In RBAC, administrators give permissions by assigning them to roles, and in addition by assigning roles to users. As you know, for a user to be able to use a particular permission, he will have to have been assigned at least one role that provides said solution.

So each user has a set of roles assigned to him. During a session, he can choose to activate (or deactivate) any of these roles, but no other. The activated roles determine which permissions are available to the user at a given time during the session. This is useful, for example, for dynamic separation of duty constraints, where two roles A and B can be assigned to the same user U, but can't be used together. Therefore, if U wants to use A, he will have to deactivate B before activating A.

1
votes

From my experience in implementing RBAC, I pretty much avoided using dynamic management of multi-sessions.

At first it sounded like a pretty neat and flexible idea, but as you questioned on who activates/deactivates roles (and when), I realized the complexity and security risks wasn't worth the effort (my personal opinion).

The important thing to understand here and for which @Imontriux (above) mentioned:

"This is useful, for example, for dynamic separation of duty constraints, where two roles A and B can be assigned to the same user U, but can't be used together. Therefore, if U wants to use A, he will have to deactivate B before activating A."

Most of the time, there are separation of duty constraints that must apply and in order to honour this, I simply chose to only have/manage one valid session per user at a time. If a user wants to authenticate under different set of roles, he/she is responsible in logging out and logging back in.

It pretty much simplified a lot of my code. It was a compromise I chose and could easily live with.