Question: Rbac And Libraries
0
gravatar for Ido M. Tamir
9.4 years ago by
Ido M. Tamir280
Austria
Ido M. Tamir280 wrote:
Hi, a) I have problems with your conception of roles in your RBAC scheme. Normally in RBAC[1] a subject can execute a transaction if the currently active roles of the user allow this. You require that the user should have all of the roles that are currently associated with the library. This makes simple things difficult and complicated things impossible. My policy should be: each user can do everything with his own dataset. the group of a user can access (view and push it to history) the library. a group of bioinformaticians can do everything with allmost all libraries. How would you implement this in your sheme which requires "all of the roles"? Would I have to create a new role for each combination of user/group/bioinformaticians? If you would require just "one of the roles", you would simply add 1) the user as a role to the lib (for everything) 2) the group the user is in as a role to the lib (for pushing to history + view if this is implemented) 3) the bioinformatician group as a role to the lib (for everything) b) An important permission would be to be able to view the item. I played around (maybe not enough) but could not find a way to really hide an item (library, folder, dataset) from the view. c) The little arrow pointing down to bring up the context-menu is very small. It would be helpful if you could maybe make it bigger or turn it into a button. thank you very much, Ido [1] http://csrc.nist.gov/groups/SNS/rbac/documents/Role_Based_Access_Contr ol-1992.html
• 884 views
ADD COMMENTlink modified 9.4 years ago • written 9.4 years ago by Ido M. Tamir280
0
gravatar for Greg Von Kuster
9.4 years ago by
Greg Von Kuster840 wrote:
Hello Ido, We're sorry to hear that you have encountered problems in working with dataset libraries and security in Galaxy. Please see my explanations below, and let me know if more clarification is needed or if you come across behavior that differs from that described. This is how Galaxy currently behaves. In Galaxy, a library, a library folder and a library dataset are all associated with 3 "library" permissions ( or privileges ): 1) modify library item: Role members can modify this library item 2) add library item: Role members can add library items to this library item 3) manage library permissions: Role members can manage roles associated with this library item These 3 privileges are all "grant" privileges in that if a user has a role that is associated with the permission, the user can perform that action. Roles can be associated with an individual user or a group, and a group can consist of 0 or more users. These 3 library level permissions are all inherited downward in the library hierarchy, so if you set permissions at the library level, any new folder added to the top level of the library will inherit these "library" permissions. The same inheritance scheme works for library folders, so if you add a sub-folder to a folder, the sub-folder will inherit the "library" permissions of it's parent folder. Changing the "library" permissions on a folder will therefore cause all newly added sub-folders to inherit those changed "library" permissions of it's parent. NOTE: this currently only works for newly added folders and library datasets, but we'll soon introduce a feature that will allow you to enforce this inheritance on existing folders and library datasets. A library datasets has 2 "library dataset" permissions in addition to the above 3 "library" permissions: 1) manage permissions: Role members can manage the roles associated with this dataset 2) access: Role members can import this dataset into their history for analysis. NOTE: Users must have every role associated with the access permission on this dataset in order to access it Again, roles can be associated with an individual user or a group, and the "library dataset" permission "manage permissions" is a grant privilege, and has the same behavior as that "library" permission. The "library dataset" permission "access" is a restrict permission. If no roles are associated with it, the library dataset is considered public, and all users can access it in the library. However, if a role is associated with the "access" permission on the library dataset, a user must have that role in order to access the dataset in the library. If more than 1 role is associated with the "access" permission, then a user must have all roles in order to access it. This is not necessarily the case - for example, user can have permission to add a library item, but not manage library permissions. What behavior are you seeing that leads you to this conclusion? This is currently possible. If the user is granted the 3 "library" permissions on the folder to which he is adding the dataset, then he will have those 3 "library" permissions on the dataset. The 2 "library dataset" permissions are taken from the user's default permissions for datasets in their histories. The users' "default permissions" are "manage permissions", with no role associated with the dataset "access" permission, making it public by default. These permissions can be changed in the user's preferences ( click the User link in the top menu bar in Galaxy ). This is possible if the user that uploads the dataset either leaves it public ( the default ), or associates a group role with the "access" privilege on the library dataset. This is possible as long as the group has a role that is associated with the various permissions on each library. Do you mean user/group ( Galaxy has no concept that would differentiate a user from a bioinformatician )? It depends on how you set up your groups of users. You could have 1 group with all users, and associate that group with a role, then associate that role with each "library" permission. Let me know if my explanations above do not make this clear. Viewing a library item is managed by the "library dataset" "access" permission. If a folder contains a public library dataset ( call it D1 ), then the library, that folder, and D1 can be seen by any user. However if the same folder contains a library dataset on which only UserA has the "access" permission ( call it D2 ), then UserA will see both D1 and D2, while all other users will see only D1. We'll take this under consideration.
ADD COMMENTlink written 9.4 years ago by Greg Von Kuster840
Unfortunately I am a bit slow and need more clarification. The behavior does not differ from what you described and there I think lies my problem. It is this NOTE that I don't understand. In every other case you allow one of each role. In this case you require that it fits all of the roles. But why do you model this permission like this - requiring all roles? I actually only talk about the "access" permission. Here the user has to have all the roles associated with him (should have pointed this out more). But then as soon as I add a new user, that should not have access to the datasets all the other users have, this policy scheme breaks down. Maybe I can explain what I intend in an example - and then you can tell me how I should actually do this: users (I simplify and say no user is in more than one group): userName group user1 group1 user2 group2 user3 bioinfo user4* group4 user4 is a collaborator of user1 - he should have access to the data of user1 - not to the rest of group1 data. Dataset owner A user1 B user2 I would normally solve my policy problem by creating the following roles: role members r_u1 user1* r_u2 user2* r_u3 user3* r_u4 user4* r_g1 group1** r_g2 group2** r_g4 group4** r_b user3 *I think galaxy automatically creates roles from users or allows association of libraries with users, so this might not be necessary. **I think galaxy automatically adds the roles of the groups one is member of to the users roles, so I don't add user1 to r_u1 etc... Then I would associate the following privileges with the datasets Dataset modify access A r_u1,r_b r_u1,r_g1,r_b,r_u4 B r_u2,r_b r_u2,r_g2,r_b Galaxy does not allow me to grant these access privileges, because there is no user having all the roles. It would be very simple to solve, if you would model the access permission like you model all the other permissions. Thank you very much for you time, ido
ADD REPLYlink written 9.4 years ago by Ido M. Tamir280
0
gravatar for Greg Von Kuster
9.4 years ago by
Greg Von Kuster840 wrote:
All roles are required because of the complication of derived permissions for datasets that are produced from running jobs on different input datasets. Take, for example, two datasets, DatasetA, and DatasetB. Access to DatasetA requires a user to be associated with RoleA, and access to DatasetB with RoleB. It follows that DatasetAB ( created by running a tool with DatasetA and DatasetB as inputs ) should have both RoleA and RoleB associated for the access permission. However, if ANY associated role was sufficient, this would allow users who are only associated either RoleA OR RoleB to view data which was originally not accessible to them. See above explanation Galaxy automatically creates a "private" role for each user, but this is the only role that is automatically created. Hopefully my comments above clarify why this is necessary. The roles associated with the access permission on a dataset are "and", not "or". Otherwise data security quickly breaks down on datasets derived from others. I agree that it's tricky, but ensuring data is only accessible by the desired users was our highest priority in implementing RBAC.
ADD COMMENTlink written 9.4 years ago by Greg Von Kuster840
0
gravatar for Ido M. Tamir
9.4 years ago by
Ido M. Tamir280
Austria
Ido M. Tamir280 wrote:
That is an important point. But if this is the best solution I am not sure yet - first I would like to get my data in, then I can think on the effects of combining them. Could you show me how I could solve the problem I presented in my previous e-mail without creating ad-hoc roles for every user combination? thank your very much, ido
ADD COMMENTlink written 9.4 years ago by Ido M. Tamir280
Scenaro: userName group user1 group1 user2 group2 user3 bioinfo user4* group4 user4 is a collaborator of user1 - he should have access to the data of user1 - not to the rest of group1 data. How to do it: SharingRoleForUser1AndUser4 - users ( user1, user4 ) Associate SharingRoleForUser1AndUser4 with the access permission on all data that you want both to be able to access, If you add additional members to group1, they will not have access to this data because they do not have SharingRoleForUser1AndUser4. Scenario: Dataset owner A user1 B user2 I would normally solve my policy problem by creating the following roles: role members r_u1 user1* r_u2 user2* r_u3 user3* r_u4 user4* r_g1 group1** r_g2 group2** r_g4 group4** r_b user3 *I think galaxy automatically creates roles from users or allows association of libraries with users, so this might not be necessary. **I think galaxy automatically adds the roles of the groups one is member of to the users roles, so I don't add user1 to r_u1 etc... Then I would associate the following privileges with the datasets Dataset modify access A r_u1,r_b r_u1,r_g1,r_b,r_u4 B r_u2,r_b r_u2,r_g2,r_b How to do it: For Dataset A: Role1 ( for "modify permissions" dataset permission on Dataset A ) - users ( user1, user3 ) Role2 ( for "access" dataset permission on Dataset A ) - users ( user1, user3, user4 ) - groups ( group1 ) For Dataset B: Role3 ( for "modify permissions" dataset permission on Dataset B ) - users ( user2, user3 ) Role4 ( for "access" dataset permission on Dataset B ) - users ( user2, user3 ) - groups ( group2 )
ADD REPLYlink written 9.4 years ago by Greg Von Kuster840
Dear Greg, thank you very much for your great patience in answering my questions in this level of detail. However I see that I would have to construct a role for every use case (which is already a PITA) and then, after combining the datasets I would risk that nobody (or maybe just the person that combined the datasets) will be able to access the derived data, because nobody will share all of these ad-hoc roles. I also saw that you have an RBACAgent class that seems - so I hope - to encapsulate all of the rules. I will try to hack around a little bit to change its behavior to my taste. Hopefully you won't hear from me for some time. best, ido
ADD REPLYlink written 9.4 years ago by Ido M. Tamir280
Please log in to add an answer.

Help
Access

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
Powered by Biostar version 16.09
Traffic: 169 users visited in the last hour