XRootD
Loading...
Searching...
No Matches
XrdSciTokens Directory Reference
+ Directory dependency graph for XrdSciTokens:

Files

 XrdSciTokensAccess.cc
 
 XrdSciTokensHelper.hh
 
 XrdSciTokensMon.cc
 
 XrdSciTokensMon.hh
 

Detailed Description

This ACC (authorization) plugin for the XRootD framework utilizes the SciTokens library to validate and extract authorization claims from a SciToken passed during a transfer.

Configured appropriately, this allows the XRootD server admin to delegate authorization decisions for a subset of the namespace to an external issuer. For example, this would allow LIGO to decide the read/write authorizations for pieces of the LIGO namespace.

Loading the plugin in the xrootd daemon

To load the plugin, using the default authorization scheme as a fallback, add the following lines to your XRootD configuration file:

ofs.authorize
ofs.authlib ++ libXrdAccSciTokens.so
# Pass the bearer token to the XRootD authorization framework.
http.header2cgi Authorization authz

Note that you will need to configure the default authorization scheme as well. If SciTokens is the only authorization scheme allowed then you can omit the "++" and all requests are required to present a valid bearer token.

Restart the xrootd daemon. The SciTokens plugin in the ofs.authlib line additionally can take a parameter to specify the configuration file:

ofs.authlib [++] libXrdAccSciTokens.so config=/path/to/config/file

If not given, it defaults to /etc/xrootd/scitokens.cfg. Restart the service for new settings to take effect.

The SciTokens plugin has multiple levels of logging output. To manage these, set:

scitokens.trace LEVEL_NAME

Valid levels include error, warning, info, debug, and all.

SciTokens Configuration File

The SciTokens configuration file (default: /etc/xrootd/scitokens.cfg) specifies the recognized issuers and maps them to the XRootD namespace. It uses the popular INI-format. Here is an example entry:

[Global]
audience = test_server
[Issuer OSG-Connect]
issuer = https://scitokens.org/osg-connect
base_path = /stash
map_subject = True
default_user = osg
name_mapfile = /path/to/mapfile

Duplicate section and settings names (not values) will take the value of the last entry in the file. For example:

[Issuer https://chtc.cs.wisc.edu/icecube]
issuer = https://chtc.cs.wisc.edu/icecube
base_path = /icecube/path1
[Issuer https://chtc.cs.wisc.edu/icecube]
issuer = https://chtc.cs.wisc.edu/icecube
base_path = /icecube/path2

Will result in a configuration with issuer = https://chtc.cs.wisc.edu/icecube and base_path = /icecube/path2.

Within the Global section, the available attributes are:

Each section name specifying a new issuer MUST be prefixed with Issuer. Known attributes are:

Group- and Scope-based authorization

WLCG tokens can contain either group- or scope-based attributes. The scope-based attributes specify a path the user is allowed to access (relative to one of the base paths). If a request is permitted via a scope-based attribute, then it is approved immediately by the plugin.

If there is a group-based attribute, then the contents are copied into XRootD's internal credential. The plugin does not necessarily immediately authorize (see the onmissing attribute) but rather can be used by a further authorization plugin.

Mapfile format

The file specified by the name_mapfile attribute can be used to perform identity mapping for a given issuer. It must parse as valid JSON and may look like this:

[
{"sub": "bbockelm", "path": "/home/bbockelm", "result": "bbockelm"},
{"group": "/cms/prod", "path": "/cms", "result": "cmsprod" comment="Added 1 Sept 2020"},
{"group": "/cms", "result": "cmsuser"},
{"group": "/cms", "result": "atlas" ignore="Only for testing"}
]

That is, we have a JSON list of objects; each object is interpreted as a rule. For an incoming request to match a rule, each present attribute must evaluate to true. In this case, the value of the result key is populated as the username in the XRootD internal credential.

The enumerated keys are:

Unknown keys are ignored.