Authorization, Mapping and Queue selection rules


ARC CE authorization and mapping rules rely on the concept of authgroups (configured by [authgroup] blocks).

Authorization and mapping in ARC6

Fig. 2 General overview of authorization and mapping concepts in ARC6

During the connection establishment and authentication process on any of the ARC CE interfaces (e.g. job submission on the figure), the Authgroup matching happened. Each authgroup represents a set of users, whose identities are matched to configured rules. The same user can match (belongs to) several authgroups.

If configured by allowaccess and denyaccess options, per-interface authorization rules will be enforced. This rules defines the list of authgoups that granted or denied access to the particular ARC CE interface. Without per-interface authorization rules, configuration access to the interface is granted to anyone who passed authentication process.


User will be successfully authenticated only in case of certificate and proxy-certificate has been passed validation.

In case of time syncronization problems, missing or invalid CA certificates and CRLs, missing VOMS LSC files, etc - the connection WILL NOT be established.

Mapping rules in ARC6 also relies on authgroup membership. Configured mapping rules are processed sequentially and define the OS account ID that will be assigned to authgroup members. Several mapping methods are available, depending on requirements.

Notice that in ARC6 authorization rules can also be enforced per-queue. It uses the same allowaccess and denyaccess options syntax as for per-interface configuration but can additionally restrict access to the particular queue. By default access to the queue granted to all users authorized on interface level.

Defining authgroups

Authgroups should be defined on the top of arc.conf using the [authgroup:groupname] block before it will be referenced in the other parts of configuration.

Each authgroup is a named object, that will be referenced by its name during authorization and mapping rules configuration. There are no special restrictions to the authgroup names except the absence of spaces, so you can even define * authgroup to blow the mind of other arc.conf readers.

Each config line in the [authgroup:groupname] block represent a matching rule that are processed sequentially.

When the matchig criteria of the rule has been satisfied by user identity - the processing stops within this authgroup.

Whether user belogns to this authgroup or not is defined by the type of rule that was matched: there are positively and negatively matching rules. By default all rules are positive (user IS a member of authgroup when matched) unless prefixed with - sign.

Matching one of the authgroups does not mean that the same user is not processed for the next authgroup. All authgroups are evaluated, even if a user already has a match with one of the earlier processed authgroups.


Notice that:

  • authgroup blocks should be defined before referencing!
  • authgroup rules within blocks are order-dependent!
  • all authgroup blocks are evaluated!

Complete list of authgroup rules can be found in the ARC Configuration Reference document. Some examples are:

[authgroup: norduguest]
-file = /etc/grid-security/banned.dns
voms = nordugrid Guests * *

[authgroup: admin]
subject = /O=Grid/O=Big VO/CN=Main Admin

[authgroup: lcas]
plugin = 10 /usr/libexec/arc/arc-lcas %D %P /usr/lib64 /etc/lcas/lcas.db

[authgroup: any]
authgroup = norduguest
authgroup = admin
authgroup = lcas

[authgroup: *]
all = yes

Applying authorization rules

You can enforce authentication restrictions on every interface. This includes:

In addition to interface level authorization, queue-level authorization can be configured using the same configuration approach,

The allowaccess confuguration option defines that the specified authgroup members are authorized to access the ARC-CE via this interface or access particular queue. A related config option denyaccess can in turns be used to reject access.

Multiple allowaccess and denyaccess authorization statements are allowed within a configuration block. These statements are processed sequentially, in the order they are specified in the config block.

The processing stops on first allowaccess or denyaccess statement matching the authgroup membership. If there are no authorization statements specified, then no additional restrictions are applied for authorizing user access and the interface or queue is open to everybody authenticated.


Default deny authorization approach can be configured using the empty authgroup.

Example: ARC6 zero configuration

In the shipped zero configuration the [authgroup: zero] is defined and applied to A-REX WS interface. The effect of this configuration is to allow access to CE only to the subjects stored in the testCA.allowed-subjects file. This file is empty by default and close down CE access until subjects are added by arcctl test-ca usercert.

file = /etc/grid-security/testCA.allowed-subjects

allowaccess = zero

Example: subject-based authorization

To authorize users based on certificate subject the subject or file rules can be used.

The file option support both:

  • plain list of subjects (each line contains only a subject name),
  • grid-mapfile format, when subject name followed by mapped account ID.

In both cases subject name should be enquoted if it contains spaces.

[authgroup: banana]
subject = /O=Grid/O=Bad Users/CN=The Worst

[authgroup: boss]
subject = /O=Grid/O=Big VO/CN=Main Boss

[authgroup: dnfromfile]
file = /etc/grid-security/local_users

denyaccess = banana
allowaccess = boss
allowaccess = dnfromfile

Example: VOMS-based authorization

To filter access based on VOMS certificate attributes, define one or more [authgroup] blocks using the voms keyword.

To verify VO membership signatures, ARC CE needs the so-called list of certificates (LSC) files that can be installed by arcctl.

Example configuration for atlas, alice and VOs [1]:

  1. Deploy LSC files:
[root ~]# arcctl deploy voms-lsc atlas --egi-vo
[root ~]# arcctl deploy voms-lsc alice --egi-vo
[root ~]# arcctl deploy voms-lsc --voms vomss://
  1. Create authorization group and apply access resctiction to interface and/or queue in arc.conf:
[authgroup: atlas]
voms = atlas * * *

[authgroup: alice]
voms = atlas * * *

[authgroup: swegrid]
voms = * * *

[authgroup: all]
authgroup = atlas
authgroup = alice
authgroup = swegrid

allowaccess = all

allowaccess = all

[queue: qlhc]
allowacces = alice
allowacces = atlas

[queue: qswegrid]
allowacces = swegrid
[1]In this example and in what follows, a simplified configuration is shown. An actual configuration will in most cases include different authgroups for different VO groups and roles.

Configure mapping

Any grid user should be mapped to a local account to start processes and access files.

Mapping rules configured in [mapping] block define which grid-users (specified by authgroup) are mapped to which system accounts (several mapping methods available).

Rules in the [mapping] block are processed in a sequence in line order of the configuration file (from top to bottom).

There are two kind of rules avaiable:

  • mapping rules (started with map_) that defines how the particular authgroup members are mapped,
  • policy rules (started with policy_) that modifies the mapping rules sequence processing.

Default policy for mapping rules processing is:

  • processing CONTINUES to the next rule if identity of user DO NOT match authgroup specified in the rule (can be redefined with policy_on_nogroup option)
  • processing STOPS if identity of user matched the authgroup specified in the mapping rule. Depend on whether this mapping rule returns valid UNIX identity the processing can be redefined with policy_on_map and policy_on_nomap options.

Policy can be redefined at the any point of configuration sequence and affects all mapping rules defined after the polcy rule.


If mapping process STOPS and there is still no local UNIX identity identified, the user running A-REX will be used (typically root unless redefined by user option for specific deployment case).

When grid-identity is mapped to root account - request processing fails implicitely!

Example: mapping to the same account

The map_to_user option allows to map all authgroup members to the same account specified as an argument.

For example in shipped zero configuration all users that are matched to authgroup zero are mapped to the same nobody account (and nobody group) that will work with local job forking:

map_to_user = zero nobody:nobody

Example: mapping to the accounts pool

The most secure and flexible way is to map authgroup members to account pools (so-called map_to_pool method). It is recommended to use pools mapping when the resource is under the use of different communities.

In this approach, every member of specified authgroup will be dynamically mapped to one of the available accounts in the configured pool.

Available pool account names are stored one per line in the pool file inside the dedicated directory. Accounts from pool are assigned by means of leasing approach. All leased accounts are stored in the other files placed in the same directory. They can be reassigned to other users after 10 days of inactivity.

Example configuration for atlas:

  1. Create necessary number of accounts to be used on ARC CE and Worked Nodes of the cluster.
  2. Define ARC accounts pool:
[root ~]# mkdir -p /etc/grid-security/pool/atlas
[root ~]# for u in atlas{001..100}; do echo $u >> /etc/grid-security/pool/atlas/pool; done
  1. Configure mapping in arc.conf [2]:
map_to_pool = atlas /etc/grid-security/pool/atlas
[2]atlas is the name used in [authgroup: atlas]

Example: Legacy grid-mapfile based mapping


Legacy grid-mapfile based mapping is NOT recommended for the typical production loads.

In the grid-mapfile approach users are mapped to local accounts based on certificate DNs only. Mapping rules are stored line-by-line in the so-called grid-mapfile that describes which user is mapped to which account, for example:

"/O=Grid/O=NorduGrid/ Konstantinov" user1
"/O=Grid/O=NorduGrid/ Smirnova" user2

In the simplest legacy case ARC can use the grid-mapfile for both authorization and mapping decisions.

Example configuration for legacy grid-mapfile case:

[authgroup: legacy]
file = /etc/grid-security/grid-mapfile

map_with_file = legacy /etc/grid-security/grid-mapfile

Grid-mapfiles in arc.conf can be also referred as a [userlist] objects and be generated regularly, keeping them up-to-date (from e.g. VOMS database) with nordugridmap utility that can be used and configured with the [nordugridmap] block


You can find more information about moving from grid-mapfiles in the The life without gridmapfiles presentation.

Example: mapping with external LCMAPS rules

ARC can run an external plugin to map users that can be configured with the map_with_plugin option.

To support several production loads, ARC ships with the built-in LCMAPS plugin included in A-REX package:

all = yes

map_with_plugin = all 30 /usr/libexec/arc/arc-lcmaps %D %P /usr/lib64 /etc/lcmaps/lcmaps-arc-argus.db arc

LCMAPS itself is a third-party tool that should be installed and configured separately, which is beyound the scope of this guide.

Queue selection rules and queue configuration


Behaviour new in ARC 6.11

Once a submitter is authorized to submit to one of the submission interfaces defined in arc.conf, the next step for ARC is to select a queue and check authorisation at queue-level.

The logic is as follows

  1. if (queue defined in job description xrsl)
  • submit to that queue w/o modification if authorised in the queue block
  1. elseif (no queue defined in job description xrsl but a default queue is defined in arc.conf)
  • substitute the default queue into xrsl if authorised in the queue block
  1. elseif (no queue in defined in job description xrsl and no default queue is defined in arc.conf and the VO is authorised in one of the arc.conf queues*)
  • substitute into xrsl the first of the queues where the VO is authorised according to arc.conf
  1. else
  • reject

* any VO is authorised in a queue that has no authorisation defined at all.

Note that this means that you must ensure that the authgroups you wish to allow submission from, are authorized in the queue you intend the authgroup to submit to. An example of an arc.conf setup that previously could result in the LRMS selecting the queue, but where submission today will be rejected could be the following:




allowaccess= exp1

allowacces= exp1

Let’s look at the exp2 authgroup. According to this arc.conf we assume the authorisation and mapping is ok.

Old behaviour: If there is no queue information in the xrls, the old behaviour would be to pass the job to the LRMS directly and let LRMS select the queue. This means that any queue in the system, even a queue not defined in arc.conf could be selected, e.g. a queue3 defined by the LRMS, but not in arc.conf.

New behaviour: From ARC version 6.11 only queue1 and queue2 will be possible queues for exp2 (and any authgroups), as they are the ones defined in arc.conf. Therefore in the example, none of the queues are allowed for exp2 and the job will be rejected.

A possible rewrite of this arc.conf example-snippet, to allow exp2 to submit to queue2 could be:

allowaccess= exp1


This is an example of rule 3: No queue is defined in the job description xrsl and no default queue is defined in arc.conf and the VO is authorised in (at least) one of the arc.conf queues. In this example all VO’s are authorised for using queue2.