Tags:
, view all tags

GACL based authorization in EMI WMS

In gLite 3.1 and EMI1 WMS, access control is implemented through a library provided by Gridsite, which uses a XML based file to set permissions on DN/FQAN. This file is called the GACL file: http://www.gridsite.org/wiki/GACL. For the record, the EMI2 release will support authZ based on a service, called Argus, more than a library like Gridsite is. Authorization based on Gridsite will still be possible, by configuration, but strongly discouraged. As documented in the WMS admin guide for EMI1, Wmproxy GACL, with EMI1 an exact match is required between the DN/FQAN expressed in the gacl file and the one in the user proxy. This represents a change with respect to the previous gLite 3.1 release, that allowed to express not well formed FQANS, i.e. without the leading / and with wildcards. The EMI1 WMS, instead, always required a valid FQAN, that in turn does not foresee wildcards in its syntax. So, for example, while in gLite 3.1 WMS the following GACL file would have been enough to grant access to all CMS users, indistinctively:

<entry><voms><fqan>cms/*</fqan></voms><allow><exec/></allow></entry>

<entry><voms><fqan>cms</fqan></voms><allow><exec/></allow></entry>

With EMI1 WMS each single group and role has to be specifed manually. For example, for VO CMS and its following roles:

/cms/Role=cmsprod

/cms/Role=cmssoft

/cms/Role=cmst1admin

the previous file would become (note the leading slash in the FQAN):

<entry><voms><fqan>/cms/Role=NULL</fqan></voms><allow><exec/></allow></entry>

<entry><voms><fqan>/cms/Role=cmsprod</fqan></voms><allow><exec/></allow></entry>

<entry><voms><fqan>/cms/Role=admin</fqan></voms><allow><exec/></allow></entry>

<entry><voms><fqan>/cms</fqan></voms><allow><exec/></allow></entry>

The GACL file is rarely edited by the admins, as it gets generated by yaim starting from file groups.conf. The groups.conf attached in this twiki comprises all the possibile combinations of existing groups/roles a significant number of VOs as of today. Each time a new group is created, this file must be edited to include all the combinations for this group and all the possibile existing roles; then, yaim must be re-run. If, for example, a new group 'team' is created in VO 'foo', here are the lines to be added to the group.conf file:

"/foo/team"::::

"/foo/team/ROLE=pilot"::::

"/foo/team/ROLE=production"::::

"/foo/team/ROLE=lcgadmin"::::

before re-running yaim. If a new role is introduced (this should be even more rare), then it must be added for each existing group. For example:

"/foo/oldteam"::::

"/foo/oldteam/ROLE=pilot"::::

"/foo/oldteam/ROLE=production"::::

"/foo/oldteam/ROLE=lcgadmin"::::

"/foo/oldteam/ROLE=newrole"::::

"/foo/newteam"::::

"/foo/newteam/ROLE=pilot"::::

"/foo/newteam/ROLE=production"::::

"/foo/newteam/ROLE=lcgadmin"::::

"/foo/newteam/ROLE=newrole"::::

-- MarcoCecchi - 2012-02-14

Topic attachments
I Attachment Action Size DateSorted descending Who Comment
Unknown file formatconf groups.conf manage 11.9 K 2012-02-14 - 11:37 MarcoCecchi  
Edit | Attach | PDF | History: r2 < r1 | Backlinks | Raw View | More topic actions...
Topic revision: r1 - 2012-02-14 - MarcoCecchi
 
  • Edit
  • Attach
This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback