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.
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.
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.
Related
I am attempting to model account access in a graph DB.
The account can have multiple users and multiple features. A user can have access to many accounts. Each account can give access to only part of the features for each user.
One way I see it is to represent access for each user through relationship attributes, this allows having a shared feature node.
user_1 has access to account_1-feature_1 and account_2-feature-2. user_1 does not have access to account_1-feature_2 even though it is enabled for the account.
Another way to model the same access, but without relationship attribute is to create account specific feature nodes.
Question 1: which of these 2 ways is a more 'proper' modeling in the graph DB world?
Now to make things more interesting the account can also have parts which can be accessed by multiple accounts and a certain feature should be able to be scoped down to only be accessible for specific part by user.
In this example user_1 can access account_1 only for part_a feature_1.
To me it seems like defining an attribute on relationship is the way to go for being able to scope down user access by feature & by part of the account. However, reading neo4j powerpoints this would be one of the code smells of relationships having "Lots of attribute-like properties". Is there a better way to approach such problem in a graph?
I could be wrong here, but here are my thoughts. Option 1 definitely sounds the better way from a modeling perspective, however, I don't see how you can keep the data consistent without building heavy machinery to do it. For example, If someone deletes Account1.Feature1, and does not update the edge from User1 -> Account1, then you end up having stale RBAC rules in the system. You think you have access to something, but in reality that "thing" does not exist anymore. Option 2 may not seem very attractive from a data model perspective, but it does keep your data consistent. If you delete Account1.Feature1, the edge is automatically deleted in the same transaction.
The only con is that, you need to incur additional cost at insertion where you need to insert a lot more nodes than Option 1. For an RBAC system, I think its a fair compromise.
The same comment applies to the second half of your question as well.
I am making an app that my company is going to use and I want the one account for each department, thus every employee from a certain department can log in and use that joint account. Can I just create an account with Meteor's account system or is it anything else I should think about?
if you mean you are going to have multiple humans share a password for an account, technically, yes that should work. Meteor supports multiple logins for a single account.
where you might run into trouble is multiple writes, e.g. if 2 people both decide to change the password.
however, just because it is technically possible, you might consider finding a way to fulfill your requirements but still allowing each human to have their own account.
for example, you could handle that with groups. each account is assigned to one or more groups, and each group shares data and functionality. if it is at all important to track who made a data change, this is a better approach.
the Meteor roles package (https://github.com/alanning/meteor-roles) could help in this regard.
I keep running into cases were I want to limit access to data rather than methods.
As an example, I have a users table. An individual user's record should be visible only to themselves, the helpdesk, and the user's manager. However, only the manager can edit the user.
I can restricted view and edit methods by the above roles using the authorization attributes, but then I still need to check and see if the current user has the ability to touch the data he is requesting. This is where the authorization attribute falls short.
I'm currently considering adding an "IsAuthorized" method to all of my models to check and see check if the current user is allowed to perform the current action, but this seems tedious in general, so I wanted to see if anyone else had a centralized way of doing this.
Thanks again!!
(Currently coding everything in ASP.NET C# MVC 4.5.)
Hi Stack Community Members,
I am developing an application under MVC3 where users have department-specific CRUD privileges. In other words, all users can view data for all departments, but only certain users can make changes to the data for any one given department. User-department privilege data is held in a join table in a database.
What I typically do in this kind of situation (in PHP) is to create a Session variable (an array) on login which is populated with the id's of the departments which the user is allowed to edit. When a user then goes to access the editing feature a drop-down list is populated with only these specific departments. I also populate a few other session variables which are used frequently like the user's name and the id of the current time period (business quarter).
Is this type of approach a good way to go in MVC3, or is some alternative approach better? While I figure that I'm going to use Forms Authentication and some specific roles (employee, admin, etc.) these types of roles are just too broad to be able to target department-by-department access, and I'm not sure that MVC3 has an out-of-the-box method which is better than what I'm planning to do.
Your guidance is appreciated!
I'm using Forms Authentication, add specific roles, and combine them if needed. I don't mind being specific for the roles, as they can be combined anyway I want. I can still have broad roles for more general actions.
I store similar data (UserId, DepartmentId, etc) in session since it does not change for the user and it is a small amount of data. It is my opinion that session state would be a good approach for you also.
I need to automatically apply a role, Role X, to all Drupal users that have been granted a separate role, Role Y. In other words, I wish for Role X to be a subset of Role Y. How can I do this?
You could implement hook_user() in a custom module. On the 'insert' and/or 'update' action, you'd check for role Y in the $account->roles array. If present, add role X if not already there. This would ensure that your rule gets applied every time a user account gets created and/or changed.
For a bootstrapping/one time operation, take a look at user_multiple_role_edit(). It lets you add or remove roles for an array of user ids. Alternatively, you could do it directly in the database:
INSERT INTO users_roles (uid, rid)
SELECT uid, [roleX_ID] AS rid FROM users_roles
WHERE uid IN
(SELECT uid FROM users_roles WHERE rid = [roleY_ID])
AND uid NOT IN
(SELECT uid FROM users_roles WHERE rid = [roleX_ID])
;
I agree with Henrik Opel on using hook_user in a custom module would be a good solution to maintain the users and make sure they are up to date all the time.
Normally I wouldn't mind writing SQL or something alike, but in this case, since it's on a production site, I would prefer a different route, since if something can easily go wrong when writing raw SQL, a little typo can cause big troubles. Another good point is that you can run into problems as drupal wont be aware of what raw SQL you run on your database and might get out of sync with some processes, hooks and other processes that's normally run when you do things through the Drupal API.
Instead you can use the drupal user admin interface. I actually think that in this case, it is the easiest way to do what you want. Simply filter all users that are students. Click all the users and give them the member role. This is done with a few clicks in no time, and is very secure since Drupal will handle all the SQL for you.
Updated
With that many users, I'm surprised that you don't have a custom user and content managing page setup using views_bulk_operations. Using a few minutes, you can setup a admin page which you can use to preform bulk operations like changing user status, roles, or perform similar tasks for nodes. You can create your own filters using exposed views filters. So with a few clicks you can select all the users with role of student and that isn't member, select them all and add the member roll to them. The advantage doing this is not only that it's quick and safe, but you can create some nice managing pages for your site administrators, content creators etc. You should consider looking into this module.
The LDAP module allows you to dynamically assign roles based on DN. I actually had to write my own module that is tailored specifically to our system, otherwise I would be more than happy to share it.
link text