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

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.

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

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.

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

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 )

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