Community
Participate
Working Groups
This bug should gather use cases and ideas about access control of grid elements. A generic approach should constructed from the listed requirements.
AWS S3 The S3 storage mechanism uses an ACL system to authorize access. A typical representation inside of gEclipse is the Connection view. Therefore the s3 elements are backed up by an EFS implementation. The access control can be applied to a bucket (folder) or a containing file. the following rights can be applied: - READ - WRITE - FULL_CONTROL - READ_ ACP (read access control properties) - WRITE_ACP (write access control properties) The identity to whom these rights can be given can either be specified by - a canonical id (think encoded user id, not very user friendly, 64 char) - group identity (human readable URI of a group; eg: http://acs.amazonaws.com/groups/global/AuthenticatedUsers ) - email address of a S3 user (the most common way to give access to one person/s3 account)
LFC's ACL looks like UNIX ones, the mapping is as follows: user - user using one's certificate, group - users gathered in one VO, others - anyone. Permissions are READ, WRITE, EXECUTE (again, similar to the UNIX ones, esp. in case of directories).
GRIA permissions system bases on PBAC and it is used not only for storage (data stagers) but for jobs and all the services. From the client point of view it looks similar to ACLs, except that it is higher level: a "who" (user, group, anybody, etc) is granted or denied belonging to a given "role" ("owner", "manager", "world", etc instead of simple read or write permissions). The available roles are (can be) different for each service, and can also be configured by the site admin. Some preliminary (still incomplete) interfaces covering these use cases are available under core.accesscontrol
(In reply to comment #3) > GRIA permissions system bases on PBAC and it is used not only for storage (data > stagers) but for jobs and all the services. Yes, we should consider that access controls should be available for any GRIA resource or service. > From the client point of view it looks similar to ACLs, except that it is > higher level: > a "who" (user, group, anybody, etc) > is granted or denied > belonging to a given "role" ("owner", "manager", "world", etc instead of > simple read or write permissions). That is more-or-less correct, at a high level. Who is actually a MatchPattern in GRIA. > The available roles are (can be) different for each service, and can also be > configured by the site admin. Correct. Also, the list of roles available for the client to see is also configurable by the service, i.e. there is a complete list (possibly only known by the software, and a subset visible to the client). I have some comments about the current content of the "Access control management" panel, at least from the GRIA perspective... Generally it looks good, and I like the icons, etc (as long as they imply the correct meanings!) However, I think that some of the column names should be changed as follows: Permission rules -> Policy Rules Policy -> Rule Type Permission -> Role Who/Name -> Match Pattern Signing CA -> Issuer Certificate These headings are based on the NextGRID security profile document at: http://www.nextgrid.org/GS/management_systems/security/NextGRID_security_profile.pdf The "Name" column doesn't make too much sense on its own, as this may not always be a name. Perhaps it is more like Value. However, I think that it is better to combine the Who/Name into Match Pattern, more like the current GRIA client. This column is then effectively "Who". I'll upload some screenshots to compare GRIA client with current g-Eclipse dialog.
Created attachment 114655 [details] Access control in GRIA client
Created attachment 114656 [details] Access control in g-Eclipse (for GRIA)
(In reply to comment #4) > Yes, we should consider that access controls should be available for any > GRIA resource or service. yes, there is Bug #245696 for the necessary client lib changes. Supporting access control on jobs themselves is a snap (although not sure if really useful), a few uncommitted lines, i was just aiming at finishing the implementation first. > > a "who" (user, group, anybody, etc) ... > That is more-or-less correct, at a high level. "Who" is actually a > MatchPattern in GRIA. yes, but nobody cares about those technical implementation details, important is how to present things to the end user to avoid confusing her... We wouldn't help anybody (besides the GRIA devels perhaps) if we use the string "Match pattern" somewhere! > However, I think that some of the column names should be changed as follows: > > Permission rules -> Policy Rules > Policy -> Rule Type > Permission -> Role > Who/Name -> Match Pattern > Signing CA -> Issuer Certificate well, that is exactly the PBAC jargon... other people use other jargon, we should try to make things "normal-user" friendly not implementation specific. Of course if the wording doesn't fit what what you are doing in a specific MW then we need to change things, but as long as you are doing plain standard Access Control (from the point of view of the user/client) let's try to use generic /friendly language... :-) Signing CA -> Issuer Certificate: yes, agree here Anyways, i think it will be more flexible to change that table into a tree allowing the MW to determine the information displayed. But as i said a working/useful implementation first! > The "Name" column doesn't make too much sense on its own, as this may not > always be a name. Perhaps it is more like Value. However, I think that it is > better to combine the Who/Name into Match Pattern, more like the current GRIA > client. This column is then effectively "Who". true, but that is the problem of trying to display a summary of all the rules in a single tables which is moreover MW-independent. As i said, i will investigate switching the implementation to use a tree to display the rules... That would make this discussion less relevant/necessary. I've changed Name-> Identification for now. BTW, in your gEclipse screenshot the "CA" column info is completely broken. There the Issuer DN should be displayed and not the full cert string ;-)
