Context and overview

Access control to the Resource Centre's resources is done on different levels. EGI Federation is a heterogenous landscape and its varying middleware means that there is no single, straightforward solution.
Below we provide a list of recommendations that a site may consider when implementing access control.

About Virtual Organisations

The user communities are organised in Virtual Organisations (VOs), and access to the resources is usually granted to the member of a VO by the VO itself.

Virtual Organisations are managed via Attribute Authorities, some well known ones are:

  • VOMS
  • PERUN
  • COManage, a component part of Check-in
In case VOs use pilot job submission systems the payload can not easily be attributed to a certain identity. EGI and WLCG are currently investigating possible solutions.

About network filtering

Some scenarios may make use of network filtering, based on origin/target IP address. Note, however, that the filtering must be done with caution. It requires knowledge about the scope of address to be blocked, which may not be always reliable. The effect may also be unnecessarily wide, preventing access to information that is not expected to be blocked.

Instead it is advisable to focus on particular users and their identities.

A matter of authorisation not authentication

The particular approach depends on the applications but it is important to stress that the problem is not related to authentication and should be addressed on the level of access control (authorisation).

The service needs to be configured to deny access to particular users. The concrete steps are always specific to the particular software, authentication and authorisation technology used and the whole eco-systems. Basically, the blocking (or hinting at least) is ideally done by the virtual organisation (community) that the user is member of, since it has the best link to the user. Another option is adapting the access control of the service to block particular users based on knowledge the service has available.

X.509-based technology

For X.509-based technology it is suggested that services populate access control lists as described in the software-specific documentation.

Removing a particular CA root certificate is not the right option: it is unlikely to effectively ban the targets (since users whose access is to be controlled, but possess a certificate from another CA are still allowed through, and CA constituencies overlap in many cases) and removal would also hinder the service operations and visibility into compliance verification, e.g. access attempts would not be visible.

SAML/OIDC technology

Services using SAML/OIDC identity providers can block users based on the origins, i.e. the identity provider. It works well for “common” identity providers that are part of eduGAIN or have direct relationship to community IdP-SP-Proxies. The "saml:AuthenticatingAuthority" from the authentication context will indicate the (URL) of the originating home IdP, also for most IdP-SP Proxies. This value can be inspected in the service. SAML meta-data can be used to associate the entityID with their federation - look for the "mdrpi:RegistrationInfo registrationAuthority" value in the corresponding EntityDescription. For users identified only using their social identifiers, additional information needs to be consulted. This is again the role the relevant community (virtual organisation) should be able to take.

Removing entities or SAML registration authorities from the meta-data feed is not the right option, for the same reasons as listed above for X.509 technology.

Technical solutions

At the VO level

Virtual Organisations are managed via Attribute Authorities, some well known ones are:

  • VOMS
  • PERUN
  • COManage, a component part of Check-in

VO managers are responsible for reviewing and controlling the VO membership. Users suspended in a VO won't be able to use any of the resources the VO is having access to.

NGI-level and site-level Argus configuration

See Argus documentation.

Suspending individual users

pap-admin ban subject $DN
pdpctl reloadPolicy
pepdctl clearResponseCache

Refreshing central suspension policy

pap-admin refresh-cache $CENTRALSUSPENSIONPOLICY
pdpctl reloadPolicy
pepdctl clearResponseCache


Use of wildcards in Argus policies

Wildcards in Argus use regex format, with the following being example policy snippets to suspend entities:

rule deny { subject-issuer = "CA string" }

rule deny { subject=".*/L=$LOCALITY/.*"}

rule deny { subject=".*/C=$COUNTRY/.*"}

LCAS/LCMAPS

The map files used for the plugins take glob(7) style wildcards by default.

Compute

ARC-CE

Banning a VO

The defined authgroup for the VO should be denied in  arc.conf using [gridftpd/jobs] and [arex/ws/jobs].

[gridftpd/jobs]
denyaccess=undesiredvo

[arex/ws/jobs]
denyaccess=undesiredvo

Banning a user

Create a new auth group in arc.conf:

[authgroup:bannedusers]
# specify the location and the file with the list of banned users' DNs
file=/etc/grid-security/banned_users

# disable gridftp submission for this group
[gridftpd/jobs]
denyaccess=bannedusers

# disable https submission for this group
[arex/ws/jobs]
denyaccess=bannedusers

Detailed instructions are available in the Nordugrid ARC documentation

Another option is using LCMAPS mapping, since ARC supports mapping with external LCMAPS rules. You can configure it with the map_with_plugin option which is described on this URL.

HT-Condor

There are several possibilities for blocking some users from HTCondor-CE.

The first is to deny authorisation based on their account name on the CE machine. This assumes the blocked users don’t use a shared account with non-blocked users. You would add entries to the DENY_WRITE configuration parameter, like so:

DENY_WRITE = $(DENY_WRITE) joe@$(UID_DOMAIN)

The second option is to block users based on the IP address they’re coming from. A wildcard or net mask can be used to block a range of client
IP address. You would add entries to the DENY_WRITE configuration parameters, like so:

DENY_WRITE = $(DENY_WRITE) */199.68.*
DENY_WRITE = $(DENY_WRITE) */128.105.128.0/17

If the users are using HTCondor ID_TOKENS for authentication, you can use the SEC_TOKEN_REVOCATION_EXPR configuration parameter to deny their tokens based on any of the tokens’ fields. It is a ClassAd expression that is evaluated against the token’s JSON data:

SEC_TOKEN_REVOCATION_EXPR = sub == “joe” || sub == “jane"

See also OSG documentation on how to ban a user using LCMAPS.

Workload Manager service

The Workload Manager service (DIRAC) keeps its own Registry of users. To control access to the service the following options are possible:

  • Drop user registration from the Registry. In this case, users will not be able to use the service
  • Set user status to Suspended with respect to a given VO or a list of VO's. The effect is the same as for the previous case, but the user Registry record is not dropped and can be resumed.
  • The Suspended status can be set to follow the corresponding user's status in VOMS for a given VO.
  • User can be defined as a member of a group with limited or no capabilities. This can allow more fine grained control of user rights, e.g. forbidding job submission.

There is currently no way to have site-specific restrictions.

As with other services, restrictions (like suspending users) can also be made at the VO level, and the service can be instructed to re-synchronise its user Registry.

Cloud Compute

The Cloud Compute infrastructure (FedCloud) is based on OpenStack.

OpenStack

There are "blacklist" and a "not_any_of" options in the keystone mapping that can be used to restrict access to OpenStack APIs.

Mappings are VO-specific, and it also requires being able to identify the users.

As with other services, restrictions can also be made at the global VO level.

It's important to realise that this access control is only at the level of the OpenStack APIs and wouldn't impact any running virtual machines, they should be considered by other means.

Storage

dCache

dCache provides a gPlazma plugin intended to ban users: banfile

This plugin is documented on this page: https://dcache.org/old/manuals/Book-7.2/config-gplazma.shtml#banfile

You can ban users by any information ("principal").  The distinguished name (DN) is an example of such a principal.

In order to ban an individual with a specific X.509 DN, you can include a line like:

   ban dn:/C=xy/O=xy/OU=xy/CN=Name Surname

in the banfile configuration file.  That file's location is configurable, but it is "/etc/dcache/ban.conf" by default.

Another possibility to ban a user is by using grid-mapfile, where DNs are mapped to a local Linux account. You can map the user to a non-existing local account:

"/C=xy/O=xy/OU=xy/CN=Name Surname" nonexistantusername

You need to rebuild the gridmapfile after that.

edg-mkgridmap --output=/etc/grid-security/grid-mapfile --safe

Or you can simply set a dash for the username:

"/C=xy/O=xy/OU=xy/CN=Name Surname" "/vo-name" -

Detailed documentation is available on the dCache website.

Providing feedback

Feedback about this page can be sent to the CSIRT IRTF, see CSIRT Contacts.

  • No labels