UNICORE/X Manual

To run UNICORE/X, you need Java (OpenJDK, Oracle or IBM). We recommend using the latest version of the OpenJDK.

If not installed on your system, you can download it from http://www.oracle.com/technetwork/java/javase/downloads/index.html

UNICORE/X has been developed and most extensively tested on Linux-like systems, but runs on MacOS/X as well.

Please note that

All these configuration options will be explained in the manual below.

UNICORE/X can be installed from either a tar.gz or zip archive, or (on Linux) from rpm/deb packages.

To install from the tar.gz or zip archive, unpack the archive in a directory of your choice. You should then review the config files in the conf/ directory, and adapt paths, hostname and ports. The config files are commented, and you can also check [ux_configuration].

To install from a Linux package, please use the package manager of your system to install the archive.

The following table gives an overview of the file locations for both tar.gz and Linux bundles.

There are two scripts that expect to be run from the installation directory. To start, do

Startup can take some time. After a successful start, the log files (e.g. LOG/startup.log) contain a message "Server started." and a report on the status of any connections to other servers (e.g. the TSI or global registry).

To stop the server, do:

Using systemd on Linux, you would do (as root)

UNICORE/X writes its log file(s) to the LOG directory. By default, log files are rolled daily, There is no automated removal of old logs, if required you will have to do this yourself.

Details about the logging configuration are given in [ux_logging].

UNICORE/X is the central component in a UNICORE system and as such has a number of interfaces to other UNICORE components, as well as many of configuration options. This section gives an overview of what can and should be configured. The detailed configuration guide follows in the next sections.

UNICORE/X is configured using several config files residing in the CONF directory, see [ux_install] for the location of the CONF directory.

The following table indicates the main configuration files. Depending on configuration and installed extensions, some of these files may not be present, or more files may be present.

UNICORE/X watches some configuration files for changes, and tries to reconfigure if they are modified, at least where possible. This is indicated in the "dynamically reloaded" column.

The properties controlling the Java virtual machine running the UNICORE/X process are configured in

These properties include basic settings (like maximum memory), see [ux_admin] for more on these.

General

UNICORE/X uses two different formats for configuration.

In this example the value of the "name" property will be "value1 value2".

You can use system environment variables within property values, e.g.

Only use this syntax ${…} to reference UNICORE/X system variables!

To use UNIX system variables e.g. in storage path definitions use the syntax $VARIABLE, i.e. WITHOUT curly braces.

Various XML dialects are being used, so please refer to the example files distributed with UNICORE for more information on the syntax. In general XML is a bit unfriendly to edit, and it is rather easy to introduce typos.

The following table gives an overview of the basic settings for a UNICORE/X server. These can be set in uas.config or container.properties. Many of the settings (e.g. security) will be explained in more detail in separate sections.

Since UNICORE/X is the central component, it is interfaced to other parts of the UNICORE architecture, i.e. the Gateway and (optionally) a Registry.

The gateway address is hard-coded into CONF/container.properties, using the "container.baseurl" property:

where Gateway_HOST and Gateway_PORT are the host and port of the gateway, and SITENAME is the UNICORE/X site name. The gateway address MUST be accessible from the UNICORE/X node!

On the gateway side, the UNICORE/X address is hard-coded as well, using an entry SITENAME=address in the connections.properties file pointing to the network address of the UNICORE/X container.

It is possible to configure UNICORE/X to contact one or more external or "global" Registries in order to publish information on crucial services there.

For example

If you want to support user authentication via Unity, you have to configure UNICORE/X to trust one or more Unity servers. This is done using the container.security.trustedAssertionIssuers property. This configures a truststore containing the certificates of all trusted Unity servers (NOT the CA certificates).

For example, to configure a directory containing the trusted certificates in PEM format:

All the usual options for configuring truststores are available here, as well, as described in Section .

In order to provide a flexible initialization process for UNICORE/X, there is a set of properties named "container.onstartup.*". The value(s) of this property consists of a whitespace separated list of Java classes which must be implementing the "Runnable" interface. Many extensions for UNICORE/X rely on an entry in this property to initialise themselves.

Security is a complex issue, and many options exist. On a high level, the following items need to be configured.

This table presents all security related options, except credential and truststore settings which are described in the subsequent section.

These properties are used to configure the server’s credential (used to make outgoing SSL connections) and truststore. The truststore controls which incoming SSL connections are accepted.

We recommend using a credential in PKCS12 or .pem format, and a directory containing .pem files as truststore.

Information on the configuration of the XNJS and TSI backend can be found in [ux_xnjs].

Information on the configuration of the storage factory service, shared storages and per-user storages attached to target systems can be found in [ux_storages].

A number of settings exist that control the the web server and the HTTPClient library used for outgoing HTTP(s) calls.

The HTTP server options are shown in the following table.

The HTTP client options are the following

The functionality of the UNICORE/X server is organised into "features", where each feature can combine services, startup code and the like.

Features are enabled by default.

Features can be disabled via configuration. It is also possible to disable single services in a feature.

This feature deals with job submission and management, as well as those storage services required for job processing.

To disable the whole feature

This feature provides storage access, storage factory service, metadata management and file transfers.

To disable the whole feature

To disable only one service, e.g. the Storage Factory

This feature provides low-level services, but also contains the RESTful APIs for jobs and data management.

This feature provides the Admin service (see [ux_admin_service])

This feature provides the Registry service. This covers both the "internal" version running in every UNICORE/X server, as well as the shared Registry that is used to store information about multiple UNICORE servers.

A setting

will enable "shared" mode. Don’t do this on a "normal" UNICORE/X server.

You can set a limit on the number of service instances (e.g. jobs) per user. This allows you to make sure your server stays nicely up and running even if flooded by jobs. To enable, edit CONF/container.properties and add properties, e.g.

The last part of the property name is the service name, see [ux_features] for the services in UNICORE/X.

When the limits are reached, the server will report an error to the client (e.g. when trying to submit a new job).

UNICORE uses the Log4j/2 logging framework. (http://logging.apache.org/log4j/2.x/manual/configuration.html). The config file is specified with a Java property log4j.configurationFile.

By default, log files are written to the the LOGS directory.

Within the logging pattern, you can use special variables to output information. In addition to the variables defined by Log4j (such as %d), UNICORE defines several variables related to the client and the current job.

A sample logging pattern might be

For more info on controlling the logging we refer to the log4j/2 documentation:

https://logging.apache.org/log4j/2.x/manual/configuration.html

Logger names are hierarchical. In UNICORE, prefixes are used (e.g. "unicore.security") to which the Java class name is appended. For example, the XUUDB connector in UNICORE/X logs to the "unicore.security.XUUDBAuthoriser" logger.

Therefore the logging output produced can be controlled in a fine-grained manner.

Here is a table of the various logger categories

Often it is desirable to keep track of the usage of your UNICORE site. The UNICORE/X server has a special logger category called unicore.services.jobexecution.USAGE which logs information about finished jobs at INFO level.

The health of a UNICORE/X container, and things like running services, lifetimes, etc. can be monitored in several ways.

It is possible to use the UNICORE commandline client (UCC) for administrative and operations tasks.

To do this you need to configure UCC with administrative privileges. One way is to add the "admin" role to your user account, and select this role when running UCC commands

or create a dedicated admin user.

Another way to do this is using the server certificate of the UNICORE/X server, which will give UCC administrator rights provided UNICORE/X is configured to accept X509 authentication.

Also you should connect directly to UNICORE/X, not to the registry as usual. Say your UNICORE/X server is running on myhost on port 7777, your preferences file would look like this

Note that the registry URL points directly to the UNICORE/X server, not to a gateway.

Some UCC commands that are useful are the list-jobs, list-sites and rest commands. Using list-jobs you can search for jobs with given properties, whereas the rest command allows to look at any resource, or even destroy resources.

To list all jobs on the server belonging to a specific user, do

where username is some unique part of the user’s DN, or the xlogin. Similarly, you can filter based on other properties of the job.

The rest command can be used to destroy resources, or look at their properties. Please see "ucc rest -h" for details.

Try

The Admin service is a powerful tool to get "inside information" about your server using the UCC (or possibly another UNICORE client) and run one of the available "admin actions", which provide useful functions.

If you have enabled the admin service, you can do

to get information about available admin services. Note that you need to have role "admin" to invoke the admin service. The output includes information about the available administrative commands. To run one of these, you can use the admin-runcommand command. For example, to temporarily disable job submission

To have a look at the internal information about a user job, try

where jobID is the unique ID of the job.

If you want to migrate a UNICORE/X server to another host, there are several things to consider. The hostname and port are listed in CONF/container.properties and usually in the Gateway’s connection.properties file. These you will have to change. Otherwise, you can copy the relevant files in CONF to the new machine. Also, the persisted state data needs to be moved to the new machine, if it is stored on the file system. If it is stored in a database, there is nothing to be done. If you are using a TSI server, you might need to edit the TSI’s properties file and update the tsi.njs_machine property.

This section describes the basic security concepts and architecture used in UNICORE/X. The overall procedure performed by the security infrastructure can be summarised as follows:

All these steps can be widely configured.

A server has a certificate, which is used to identify the server when it makes a web service request. This certificate resides in the server keystore, (see [ux_configuration]).

A user request is assigned an identity during the authentication process. Identities are X.500 distinguished names. Requests without authentication are anonymous and are usually limited to informational endpoints.

When a client makes a request to UNICORE/X, a number of tokens are read from the message headers. These are placed in the security context for the current request.

Each service is owned by some entity identified by an X.500 distinguished name. By default, the server is the owner. When a resource is created on user request (for example when submitting a job), the user is the owner.

Messages can be sent from other servers on behalf of an end user. The server will "prove" this by using a JWT token for authentication, which contains the target user’s identity (X500 name), and which is signed by the sending server. The receiving server can check the signature with the sender’s public key, which will generally be read from the shared registry.

UNICORE/X retrieves user attributes using either a local component or a remote service. For example, an XUUDB attribute service can be configured. See [use_aip] for more information.

Each request is checked based on the following information.

The validation is performed by the PDP (Policy Decision Point). The default PDP uses a list of rules expressed in XACML 2.0 format that are configured for the server. The [use_pdp] describes how to configure different engines for policy evaluation including a remote one.

A request is allowed, if the PDP allows it, based on the user’s attributes.

UNICORE’s RESTful APIs require configuration of the mechanisms for end user authentication, which will check the supplied credentials and map the user to a distinguished name (DN).

This configuration is done in the container config file (typically uas.config or container.properties).

The enabled authentication options and their order are configured using a list of enabled mechanisms. For example

As you can see, you can use one or more authentication methods, UNICORE will try all configured authentication options in order.

For each enabled option, a set of additional properties is used to configure the details (for example the Unity address)

The FILE mechanism uses a map file containing username, password and the DN. Required configuration is the location of the file.

The file format is

i.e. each line gives the username, the hashed password, the salt and the user’s DN, separated by colons. To generate entries, i.e. to hash the password correctly, the md5sum utility can be used. For example, if your intended password is test123, you could do

which will output the salted and hashed password. Here we generate a random string as the salt. Enter these together with the username, and the DN of the user into the password file.

This mechanism uses the OAuth2 token sent from the client (HTTP "Authorization: Bearer …" header) to authenticate to Unity. In Unity terms, this uses the endpoint of type "SAMLUnicoreSoapIdP" with authenticator of type "oauth-rp with cxf-oauth-bearer".

UNICORE must be configured to trust the assertions issued by the Unity server, please refer to the relevant section on trusted assertion issuers in the manual.

This mechanism takes the username/password sent from the client (HTTP Basic auth) and uses this to authenticate to Unity, retrieving an authentication assertion.

UNICORE must be configured to trust the assertions issued by the Unity server, please refer to the relevant section on trusted assertion issuers in the manual.

UNICORE supports X.509 client certificates for authentication.

This authentication module allows to authenticate users with the username and password that they have on the UNICORE/X system.

The parameter "DNTemplate" is used to define which DN will be assigned to authenticated users, where the "%s" will be replaced by the user name. In the example above, user "test-user" will have the DN "CN=test-user, OU=pam-local-users".

There is also a PAM attribute source that you can use to automatically assign role="user" as well the Unix login and groups correctly for authenticated users.

It is also possible in principle to directly authenticate to an OAuth2 server, contact unicore-support for details.

Beginning with UNICORE 8.0.0, delegation is fully supported for REST services. The delegating server creates a JWT token containing user authentication information and signs it with its private key. The receiving server can check the signature using the sender’s public key.

Public keys are distributed via the shared service Registry.

The lifetime of the issued tokens is 300 seconds by default, which can be changed via

For very simple cases, e.g. when no shared registry is used, a shared hmac secret can be configured as well. The length of the secret must be at least 32 characters

This secret must be the same on all the UNICORE servers that are supposed to trust each other.

The authorization process in UNICORE/X requires that each UNICORE user (identified by an X.500 DN) is assigned some attributes such as her role. Attributes are also used to subsequently run tasks for the authorized user and possibly can be used for other purposes as well (for instance for accounting).

Therefore the most important item for security configuration is selecting and maintaining a so called attribute source (called sometimes attribute information point, AIP), which is used by USE to assign attributes to UNICORE users.

Several attribute sources are available, that can even be combined for maximum flexibility and administrative control.

There are two kinds of attribute sources:

Note that actual names of the attributes presented here are not very important. Real attribute names are defined by attribute source (advanced attribute sources, like Unity/SAML attribute source, even provide a possibility to choose what attribute names are mapped to internal UNICORE attributes). Therefore it is only important to know the concepts represented by the internal UNICORE attributes. On the other hand the values which are defined below are important.

The attributes in UNICORE can be multi-valued.

There are two special authorization attributes:

There are several attributes used for incarnation:

Finally UNICORE can consume other attributes. All other attributes can be used only for authorization or in more advanced setups (for instance using the UNICORE/X incarnation tweaker). Currently all such additional attributes which are received from attribute source are treated as XACML attributes and are put into XACML evaluation context. This feature is rather rarely used, but it allows for creating a very fine grained authorization policies, using custom attributes.

Particular attribute source define how to assign these attribute to users. Not always all types of attributes are supported by the attribute source, e.g. XUUDB can not define (among others) per-user queues or VOs.

After introducing all the special UNICORE attributes, it must be noted that those attributes are used in two ways. Their primary role is to strictly define what is allowed for the user. For instance the 'Xlogin' values specify the valid uids from which the user may choose one. One exception here is Add operating system groups - user is always able to set this according to his/her preference.

The second way of using those attributes is to specify the default behavior, when the user is not expressing a preference. E.g. a default Group (which must be single valued) specify which group should be used, if user doesn’t provide any.

Attribute sources define the permitted values and default values for the attributes in various ways. Some use conventions (e.g. that first permitted value is a default one), some use a pair of real attributes to define the valid and default values of one UNICORE attribute.

To configure the static attribute sources, the container.security.attributes.order property in the configuration file is used. This is a space-separated list with attribute sources names, where the named attribute sources will be queried one after the other, allowing you to query multiple attribute sources, override values etc.

A second property, container.security.attributes.combiningPolicy, allows you to control how attributes from different sources are combined.

For example, the following configuration snippet

will declare two attribute sources, "XUUDB" and "FILE", which should be both queried and combined using the MERGE_LAST_OVERRIDES policy.

Since multiple attribute sources can be queried, it has to be defined how attributes will be combined. For example, assume you have both XUUDB and FILE, and both return a xlogin attribute for a certain user, say "xlogin_1" and "xlogin_2".

The different combining policies are

Each of the sources needs a mandatory configuration option defining the Java class, and several optional properties that configure the attribute source. In our example, one would need to configure both the "XUUDB" and the "FILE" source:

Additionally you can mix several combining policies together, see "Chained attribute source" below for details.

The XUUDB is the standard option in UNICORE. It has the following features:

Full XUUDB documentation is available from http://www.unicore.eu/documentation/manuals/xuudb

To enable and configure the XUUDB as a static attribute source, set the following properties in the configuration file:

To enable and configure the XUUDB as a dynamic attribute source, set the following properties in the configuration file:

UNICORE supports SAML attributes, which can be either fetched by the server or pushed by the clients, using a Virtual Organisations aware attribute source. In the most cases Unity is deployed as a server providing attributes and handling VOs, as it supports all UNICORE features and therefore offers a greatest flexibility, while being simple to adopt. SAML attributes can be used only as a static attribute source.

The SAML attribute source is described in a separate section: [use_vo].

This attribute source uses a single map file to map DNs to xlogin, role and other attributes (only static mappings are possible). It is useful when you don’t want to setup an additional service like the XUUDB, or when you want to locally override attributes for selected users (e.g. to ban somebody).

In contrast to the XUUDB, the File attribute source can store all types of attributes, while the XUUDB only handles role, uid and group.

To use, set

The map file itself has the following format:

You can add an arbitrary number of attributes and attribute values.

The matching option controls how a client’s DN is mapped to a file entry. In strict mode, the canonical representation of the key is compared with the canonical representation of the argument. In regexp mode the key is considered a Java regular expression and the argument is matched with it. When constructing regular expressions a special care must be taken to construct the regular expression from the canonical representation of the DN. The canonical representation is defined here. (but you don’t have to perform the two last upper/lower case operations). In 90% of all cases (no multiple attributes in one RDN, no special characters, no uncommon attributes) it just means that you should remove extra spaces between RDNs.

The evaluation is simplistic: the first entry matching the client is used (which is important when you use regular expressions).

The attributes file is automatically refreshed after any change, before a subsequent read. If the syntax is wrong then an error message is logged and the old version is used.

Recognized attribute names are:

Attributes with those names (case insensitive) are handled as special UNICORE incarnation attributes. The correspondence should be straightforward, e.g. the xlogin is used to provide available local OS user names for the client.

For all attributes except of the supplementaryGroups the default value is the first one provided. For supplementaryGroups the default value contains all defined values.

You can also define other attributes - those will be used as XACML authorization attributes, with XACML string type.

This is a special attribute source which only works in conjunction with the corresponding REST authentication module.

Chained attribute source is a meta source which allows you to mix different combining policies together. It is configured as other attribute sources with two parameters (except of its class): order and combiningPolicy. The result of the chain attribute source is the set of attributes returned by the configured chain.

Let’s consider the following example situation where we want to configure two redundant Unity servers (both serving the same data) to achieve high availability. Additionally we want to override settings for some users using a local file attribute source (e.g. to ban selected users, by assigning them the banned role).

UNICORE stores its state in data bases. The information that is stored depends on the services that are running in the container, and can include

etc.

The job directories themselves reside on the target system, but UNICORE keeps additional information (like, which UNICORE user owns a particular job).

The data on user resources is organised by service name, i.e. each service (for example, JobManagement) stores its information in a separate database table (having the same name as the service, e.g. "JobManagement").

The UNICORE persistence layer offers three kinds of storage:

While the first one is very easy to setup, and easy to manage, the second option allows advanced setups like clustering/load balancing configurations involving multiple UNICORE/X servers sharing the same persistent data. Using MySQL has the additional benefit that the server starts up faster.

Data migration from one database system to another is in principle possible, but you should select the storage carefully before going into production. In general, if you do not require clustering/load balancing, you should choose the default filesystem option, since it is less administrative effort.

Peristence properties are configured in two files:

It is recommended to specify a configuration file using the persistence.config property. Thus, persistence configuration can be easily shared between the job (XNJS) data and other service data. If the "persistence.config" property is set, the given file will be read as a Java properties file, and the properties will be used.

By default, caching of data in memory is enabled. It can be switched off and configured on a per-table (i.e. per entity class) basis. If you have a lot of memory for your server, you might consider increasing the cache size for certain components.

For example, to set the maximum size of the JOBS cache to 1000, you’d configure

H2 is a pure Java database engine. It can be used in embedded mode (i.e. the engine runs in-process), or in server mode, if multiple UNICORE servers should use the same database server. For more information, visit http://www.h2database.com

In H2 server mode, the connection URL is constructed as follows

The MySQL database engine does not need an introduction. To configure its use for UNICORE persistence data, you need to set

To use MySQL, you need access to an installed MySQL server. It is beyond the scope of this guide to describe in detail how to setup and operate MySQL. The following is a simple sequence of steps to be performed for setting up the required database structures.

The UNICORE persistence properties would in this case look like this:

If you want to store data from multiple UNICORE servers, make sure to use a different database for each of them.

If you intend to run a configuration with multiple UNICORE servers accessing a shared database, you need to enable clustering mode by setting a property

The clustering config file can be set using a (per-table) property

If this is not set, a default configuration is used.

For clustering, the Hazelcast library is used (https://hazelcast.org/documentation). A basic TCP based configuration is

The most important part is the "tcp-ip" setting, which must list at least one other node in the cluster. The "group" setting allows to run multiple clusters on the same set of hosts, just make sure that the group name is the same for all nodes in a cluster.

The XNJS is an internal UNICORE/X component that deals with the actual job execution and file system access. It is configured using a properties file named xnjs.properties. It is include’d from the main config file.

Here’s an overview of the most important properties that can be set in this file.

Most of the other settings in this file are used to configure the internals of the XNJS and should usually be left at their default values.

This section describes installation and usage of the UNICORE TSI. This is a mandatory step if you want to interface to batch systems such as Slurm to efficiently use a compute cluster.

In a nutshell, you have to perform the following steps

The TSI is a service that is running on the target system. In case of a cluster system, you’ll need to install it on the frontend machine(s), i.e. the machine from where your jobs are submitted to the batch system. There are different variants available for the different batch systems such as Torque or SGE.

Usually installation and start of the TSI will be performed as the root user. The TSI will then be able to change to the current Grid user’s id for performing work (Note: nothing will ever be executed as "root"). You can also use a normal user, but then all commands will be executed under this user’s id.

As the TSI is a central and sensitive service, make sure to read its documentation. This guide serves just as a quick overview of the necessary steps.

When prompted for the path, choose an appropriate on, denoted <your_tsi> in the following

Configuration is done by editing <tsi_conf_dir>/tsi.properties At least check the following settings:

Edit unicorex/conf/uas.config and check that the "xnjs.properties" file is included

Edit unicorex/conf/xnjs.properties. Check the filespace location, this is where the local job directories will be created. On a cluster, these have to be on a shared part of the filesystem. Also, the filespace location has to be read/write/executable for the current user. If you wish to avoid a world-executable directory, it is possible to use a per-user location, like $HOME/UNICORE_Jobs.

Check the CLASSICTSI related properties. Set the correct value for the machine and the ports (these can usually be left at their default values). The CLASSICTSI.machine property is a comma separated list of machines names or IP addresses. Optionally, a port number can be added to each entry, separated from the machine by a colon. The XNJS will establish connections to each of these machines and ports in a round-robin fashion to ensure that jobs can be submitted and job statuses retrieved even if one of the TSI instances is unavailable. Should the port not be given along with the machine, CLASSICTSI.port will be used as a default.

Here is an small example.

Some additional parameters exist for tuning the XNJS-TSI communication.

UNICORE uses the normal batch system commands (e.g. qstat) to get the status of running jobs. There is a special case if a job is not listed in the qstat output. UNICORE will then assume the job is finished. However, in some cases this is not true, and UNICORE will have a wrong job status. To work around, there is a special property

If the value is larger than zero, UNICORE will re-try to get the job status.

The UNICORE/X server can be set up to use SSL for communicating with the UNICORE TSI. On the UNICORE/X side, this is very simple to switch on. In the XNJS config file, set the following property to false (by default it is set to true):

To setup the TSI side, please refer to the TSI manual!

In the special case that the XNJS callback port is not accessible from the TSI server, you may want to use an SSH tunnel configuration. For example, this case occurs if the TSI is running in a different location (e.g. an Amazon cloud) than the UNICORE/X server.

We recommend using the tool "autossh", and adding the tunnel setup to to your UNICORE/X start script.

Here is an example how to do this

Here is a full list of TSI-related parameters.

In some situations (e.g. in a Windows-only environment) you will not use the UNICORE TSI, which is designed for multi-user Unix environments. The XNJS can run code in an "embedded" mode on the UNICORE/X machine. Note that this is without user switching, and inherently not secure as user code can access potentially sensitive information, such as configuration data. Also, there is no separation of users.

Embedded mode is enabled in xnjs.properties file by setting

The embedded mode can be configured with a set of properties which are listed in the following table.

The UNICORE IDB (incarnation database) contains information on the target system capabilities (like number of nodes, CPUs etc) and allowing to check client resource requests against these.

The second IDB function is to define abstract application definitions that are then mapped onto concrete executables. This process (called "incarnation") is performed by the XNJS component.

The IDB file is defined by the property "XNJS.idbfile", which must point to a file or directory on the UNICORE/X machine which is readable by the UNICORE/X process.

While the IDB can be put into a single file, it can be convenient to use multiple files. In this case, the property "XNJS.idbfile" points to a directory. The information from all files in this directory is merged.

When using a directory, you can optionally specify a "main" IDB file containing applications, resources, properties etc. From other files, only Applications will be read. A main IDB file is defined via "XNJS.idbfile.main"

Sometimes it is required to define special applications for (groups of) users, and even let users define their own applications. This means that the set of available applications differs between users.

User specific applications can be defined using additional properties, for example like this:

These paths are resolved on the TSI machine, NOT on UNICORE/X. As you can see, they can contain variables (using $VARIABLE syntax WITHOUT curly braces!). Make sure that the numbering is consistent (ext.1,ext.2,…).

Here are a few common IDB config examples

Single IDB file (default)

IDB directory, all files are merged

IDB directory, main file defined, read apps from all other files

IDB directory, main file defined, user-specific extension

Starting with UNICORE 8.0, the IDB is written in JSON. This documentation focuses on the JSON format.

The IDB contains Partitions, Applications, Submit/Excute script templates and Info elements, all of which will be described below. Additionally the administrator can customize the script template that is used to

Applications can also be defined in separate files (if using a directory)

Each Partition corresponds essentially to a batch queue. Each partition may have its own runtime limits, number of CPUs etc.

Let’s look at an example first. In the IDB file

If you have more than one Partition, make sure to set one as the default using the element

Here you can specify things like number of nodes, job runtime (wall time!) CPUs per node, total number of CPUs, etc.

Integer-valued capabilities are specified with a range and an optional default, for example:

or in a more verbose style:

If a default is specified, the resource is part of the site’s default resource set, and a value will be always be sent to the TSI.

If NO default is specified, the resource request will only be sent to the TSI if the user has requested it in her job.

A number of standard resource names exist, which a system should adhere to, in order to make user jobs as portable as possible. You may choose to not specify some of them, if they do not make sense on your system. For example, some sites do not allow the user to explicitely select nodes and processors per node, but only "total number of CPUs", or only "Nodes".

Many resource managers support submission of job arrays, i.e. multiple similar jobs are submitted at the same time, where the user can control two things: how many jobs are submitted, and how many jobs run at the same time.

To enable this feature, the site administrator needs to define two resources in the IDB partition(s), named "ArraySize" and "ArrayLimit".

Consider the following example:

The array size and limit are passed to the TSI via

The TSI also sets an environment variable in the job script that corresponds to the "task id", i.e. the ID of the current job instance:

Most HPC sites have special settings that cannot be mapped to the generic resource elements shown in the previous section. Therefore UNICORE allows to define custom system settings and allow users to request these in their UNICORE jobs.

UNICORE/X will send these to the TSI in upper case, with a "#TSI_SSR_" prefix, e.g.

If you need to modify the scripts that are generated by UNICORE/X and sent to the TSI, you can achieve this using two entries in the IDB.

(JSON requires this as a single-line string)

The SubmitScriptTemplate is used for batch job submission, the ExecuteScriptTemplate is used for everything else (e.g. creating directories, resolving user’s home, etc)

UNICORE/X generates the TSI script as follows:

Modifying these templates can be used to perform special actions, such as loading modules, or changing the shell (but use something compatible to sh). For example, to add some special directory to the path for user scripts submitted in batch mode, you could use

For example

Simple key-value pairs can be entered into the IDB which are then accessible client-side. This is very useful for conveying system-specifics to client code and also to users.

Here is an example

These pieces of information are accessible client side as part of the target system properties.

Apart from describing the available queues and their associated resources, the most important functionality of the IDB is defining applications.

Applications can be defined in the main IDB file,

or in separate files (one application per file).

Here is a quick overview of the available elements, which will be documented in detail below.

Here is an example:

Here is an example entry for the "Date" application on a UNIX system

Invoking the "Date" application will be simply mapped to an invocation of "/bin/date".

Command line arguments are specified using <Argument> tags:

This would result in a command line "/bin/ls -l -t".

The job submission from a client usually contains environment variables to be set when running the application. It often happens that a certain argument should only be included if a corresponding environment variable is set. This can be achieved by using "conditional arguments" in the incarnation definition. Conditional arguments are indicated by a quastion mark "?" appended to the argument value:

Here, -cp$CLASSPATH? is an optional argument.

If the user’s job submission now includes a environment variable named CLASSPATH the incarnated commandline will be "/usr/bin/java -cp$CLASSPATH …", otherwise just "/usr/bin/java …".

This allows very flexible incarnations.

To set environment variables, add a map

Sometimes it is useful to be able to execute one or several commands before or after the execution of an application, for example, to perform some pre- or postprocessing. These pre/post commands are executed on a login node (i.e. they are not part of the batch job).

These commands will be executed as part on a batch node of the user’s job script, and are placed before / after the application executable command.

If an application should not be submitted to the batch system, but be run on the login node (i.e. interactively), a flag in the IDB can be set:

By default, a UNICORE job will be set to NOT_SUCCESSFUL if the application exits with a non-zero exit code. If you want to change this behaviour, you can set a flog

For client components it can be useful to have a description of an application in terms of its arguments. This allows for example the UNICORE Portal to automatically build a nice GUI for the application.

The meaning of the attributes should be fairly obvious.

If the application requires any default resources, like particular node constraints, or a specific queue, you can add resource requests in the IDB.

For example:

Note that the user job can override these, i.e. if the user requests different values for the requested resources, the values from the user job will be used.

In UNICORE the term incarnation refers to the process of changing the abstract and probably universal grid request into a sequence of operations local to the target system. The most fundamental part of this process is creation of the execution script which is invoked on the target system (usually via a batch queuing subsystem (BSS)) along with an execution context which includes local user id, group, BSS specific resource limits.

UNICORE provides a flexible incarnation model - most of the magic is done automatically by TSI scripts basing on configuration which is read from the IDB. IDB covers script creation (using templates, abstract application names etc). Mapping of the grid user to the local user is done by using UNICORE Attribute Sources like the XUUDB.

In rare cases the standard UNICORE incarnation mechanism is not flexible enough. Typically this happens when the script which is sent to TSI should be tweaked in accordance to some runtime constraints. Few examples may include:

Those and all similar actions can be performed with the Incarnation tweaking subsystem. Note that though it is an extremely powerful mechanism, it is also a very complicated one and configuring it is error prone. Therefore always try to use the standard UNICORE features (like configuration of IDB and attribute sources) in the first place. Treat this incarnation tweaking subsystem as the last resort!

To properly configure this mechanism at least a very basic Java programming language familiarity is required. Also remember that in case of any problems contacting the UNICORE support mailing list can be the solution.

It is possible to influence incarnation in two ways:

The first BEFORE-SCRIPT option is suggested: it is much easier as you have to modify some properties only. In the latter much more error prone version you can produce an entirely new script or just change few lines of the script which was created automatically. It is also possible to use both solutions simultaneously.

Both approaches are configured in a very similar way by defining rules. Each rule has its condition which triggers it and list of actions which are invoked if the condition was evaluated to true. The condition is in both cases expressed in the same way. The difference is in case of actions. Actions for BEFORE-SCRIPT rules can modify the incarnation variables but do not return a value. Actions for AFTER-SCRIPT read as its input the original TSI script and must write out the updated version. Theoretically AFTER-SCRIPT actions can also modify the incarnation variables but this doesn’t make sense as those variables won’t be used.

By default the subsystem is turned off. To enable it you must perform two simple things:

The following example shows how to set the configuration file to the value conf/incarnationTweaker.xml:

The contents of the rules configuration file must be created following this syntax:

Each rule must conform to the following syntax:

The rule’s attribute finishOnHit is optional, by default its value is false. When it is present and set to true then this rule becomes the last rule invoked if it’s condition was met.

You can use as many actions as you want (assuming that at least one is present), actions are invoked in the order of appearance.

Rule conditions are always boolean expressions of the Spring Expression Language (SpEL). As SpEL can be also used in some types of actions it is the most fundamental tool to understand.

Full documentation is available here: http://static.springsource.org/spring/docs/3.0.0.M3/spring-framework-reference/html/ch07.html

The most useful is the section 7.5: http://static.springsource.org/spring/docs/3.0.0.M3/spring-framework-reference/html/ch07s05.html

Actions can be also coded using the Groovy language. You can find Groovy documentation at Groovy’s web page: http://groovy.codehaus.org

Rule conditions are always Spring Expression Language (SpEL) boolean expressions. To create SpEL expressions, the access to the request-related variables must be provided. All variables which are available for conditions are explained in [xnjs-dynamicincarnation-context].

There are the following action types which you can use:

All actions have access to the same variables as conditions; see [xnjs-dynamicincarnation-context] for details.

There are the following action types which you can use:

All actions have access to the same variables as conditions; see [xnjs-dynamicincarnation] for details.

Invoking a logging script for users who have the specialOne role. Note that the script is invoked with two arguments (role name and client’s DN). As the latter argument may contain spaces we surround it with quotation marks.

A more complex example. Let’s implement the following rules:

The realization of the above logic can be written as follows:

Remember that some characters are special in XML (e.g. < and &). You have to encode them with XML entities (e.g. as &lt; and &gt; respectively) or put the whole text in a CDATA section. A CDATA section starts with "<![CDATA[" and ends with "]]>". Example:

Note that usually it is better to put Groovy scripts in a separate file. Assuming that you placed the contents of the groovy AFTER-action above in a file called /opt/scripts/filter1.g then the following AFTER-SCRIPT section is equivalent to the above one:

It is possible to fail the job when a site-specific condition is met. E.g. with the groovy script:

To check your rules when you develop them, it might be wise to enable DEBUG logging on incarnation tweaker facility. To do so add the following setting to the logging.properties file:

You may also want to see how the final TSI script looks like. Most often TSI places it in a file in job’s directory. However if the TSI you use doesn’t do so (e.g. in case of the NOBATCH TSI) you can trigger logging of the TSI script on the XNJS side. There are two ways to do it. You can enable DEBUG logging on the unicore.xnjs.tsi.TSIConnection facility:

This solution is easy but it will produce also much more of additional information in you log file. If you want to log TSI scripts only, you can use AFTER-SCRIPT rule as follows:

The above rule logs all requests to the normal UNICORE/X log file with the INFO level.

Dynamic incarnation tweaker conditions and also all actions are provided with access to all relevant data structures which are available at XNJS during incarnation.

The following variables are present:

Each of the available variables has many properties that you can access. It is best to check source code of the class to get a complete list of them. You can read property X if it has a corresponding Java public Type getX() method. You can set a property Y if it has a corresponding Java public void setY(Type value) method.

Let’s consider the variable client. In the Client class you can find methods:

This means that the following SpEL condition is correct:

Note that it is always a safe bet to check first if the value of a property is not null.

Moreover you can also set the value of the distinguished name in an action (this example is correct for both SpEL and Groovy):

Often the interesting property is not available directly under one of the above enumerated variables. In case of the client variable one example may be the xlogin property holding the list of available local accounts and groups and the ones which were selected among them.

Example of condition checking the local user id:

Setting can also be done in an analogous way. However always pay attention to the fact that not always setting a value will succeed. E.g. for Xlogin it is possible to set a selected xlogin only to one of those defined as available (see contents if the respective setSelectedLogin() method). Therefore to change local login to a fixed value it is best to just override the whole XLogin object like this (SpEL):

As it is bit difficult to manipulate the resources requirements object which is natively used by UNICORE, it is wrapped to provide an easier to use interface. The only exposed properties are those requirements which are actually used by UNICORE when the TSI script is created.

You can access the low level (and complicated) original resources object through the resources.allResources property.

When executing user jobs, the XNJS also performs data staging, i.e. getting data from remote locations before starting the job, and uploading data when the job has finished. A variety of protocols can be used for data movement, including UNICORE-specific protocols such as BFT or UFTP, but also standard protocols like ftp, scp, and e-mail.

Some of these (like mail) have additional configuration options, which are given in this section.

UNICORE supports file staging in/out using SCP with username/password authentication. The source/target URL schema is "scp://"

At a site that wishes to support SCP, the UNICORE server needs to be configured with the path of an scp wrapper script that can pass the password to scp, if necessary.

If not already pre-configured during installation, you can configure this path manually in the XNJS config file

A possible scp wrapper script written in TCL is provided in the "extras" folder of the core server bundle, for your convenience it is reproduced here. It requires TCL and Expect. You may need to modify the first line depending on how Expect is installed on your system.

Similar scripts may also be written in other scripting languages such as Python.

UNICORE supports file staging out using email. An existing SMPT server or some other working email mechanism is required for this to work.

The source/target URL scheme is "mailto:". You can append a subject, for example "mailto:user@domain?subject=Your output is ready"

Without any configuration, UNICORE will use JavaMail and attempt to use an SMTP server running on the UNICORE/X host, expected to be listening on port 25 (the default SMTP port).

To change this behaviour, the following properties can be defined (in the XNJS config file). See the next section if you do not want to use an SMTP server directly.

As an alternative to using JavaMail, the site admin can define a script which is executed (as the current UNICORE user) to send email.

This is expected to takes three parameters: email address, file to send and a subject. An example invocation is

UNICORE can use GridFTP client tools for stage-in/stage-out provided the client uploads the required proxy certificate. The proxy cert is expected in a file ".proxy" in the job’s working directory.

GridFTP usage can be customised using two settings in the XNJS config file ("xnjs.properties").

The configuration settings related to data staging are summarized in the following table.

UFTP is a high-performance file transfer protocol. For using UFTP as a data staging and file upload/download solution in UNICORE, a separate server (uftpd) is required. This is installed on a host with direct access to the file system, usually this is a cluster login node, but it can also be a separate host.

In a UFTP transfer, one side acts as a client and the other side is the uftpd server. UNICORE/X will run the client code via the TSI (recommended) or in-process (with lower performance)

For details on how to install the uftpd server please refer to the separate UFTPD manual available on unicore.eu, which provides all information required to install and configure the UFTPD.

The minimal required UNICORE/X configuration consists of the listen and command addresses of the UFTPD server and the location of the client executable on the TSI host.

If you want to run the client code in the UNICORE/X process, set

The following table shows all the available configuration options for UFTP.

Since UNICORE 8.1, you can optionally configure multiple UFTPD servers that will then be used in a round-robin fashion, to increase performance and scalability.

The configuration is similar to the simple case, but you can have multiple "blocks" of servers.

As an example, consider this configuration of two UFTPD servers:

Use consecutive numbers (1,2, …) to define servers.

A UNICORE/X server can make storage systems (e.g. file systems) accessible to users in several ways.

Storages have additional features which are covered in other sections of this manual.

Storage services are created on server startup and published in the registry. They are independent of any compute services and accessible for all users.

The basic property controls which storages are enabled

Each enabled storage is configured using a set of properties.

For example to define a storage for accessing the user’s HOME and some shared path

The name parameter will be used as the storage’s service ID. This means that the URL to access these storages will be something like

and via the SOAP/XML interfaces

Usually, the "name" property is not needed, if you set it it should match the ID to avoid confusion.

The other storage properties (see the previous section) are also accepted!

Each TargetSystem instance can have one or more storages attached to it. Note that this is different case from the shared storages which are not attached to any particular TargetSystem. The practical difference is that to use storages attached to a TargetSystem, a user must first create one.

By default, NO storages are created.

For example, to allows users access their home directory on the target system, you need to add a storage. This is done using configuration entries in uas.config.

Here, "N" stands for an identifier (e.g. 1,2, 3, …) to distinguish the storages. For example, to configure three storages (Home, one named TEMP pointing to "/tmp" and the other named DEISA_HOME pointing to "$DEISA_HOME") you would add the following configuration entries in uas.config:

By default storage resource names (used in storage address) are formed from the owning user’s xlogin and the storage type name, e.g. "someuser-Home". This is quite useful as users can write a URL of the storage without prior searching for its address. However if the site’s user mapping configuration maps more than one grid certificate to the same xlogin, then this solution is not acceptable: only the first user connecting would be able to access her/his storage. This is because resource owners are expressed as grid user names (certificate DNs) and not xlogins. To have unique, but dynamically created and non user friendly names of storages (and solve the problem of non-unique DN mappings) set this option in uas.config:

The StorageFactory service allows clients to dynamically create storage instances. These can have different types, for example you could have storages on a normal filesystem, and other storages on an S3 cluster.

The basic property controls which storage types are supported

Each supported storage type is configured using a set of properties

For example

The "path" parameter determines the base directory used for the storage instances (i.e. on the backend), and the unique ID of the storage will be appended automatically.

The "cleanup" parameter controls whether the storage directory will be deleted when the storage is destroyed.

It is also possible to let the user control the path of the dynamic storage, by sending a "path" parameter when creating the storage. For example, the user can use UCC to create a storage:

This will create a storage resource for accessing the given directory. In this case, there will be no cleanup, and no appended storage ID.

The normal storage properties (see the previous section) are also accepted: "type", "class", "filterFiles" etc.

If you have a custom storage type, an additional "class" parameter defines the Java class name to use (as in normal SMS case). For example:

For each UNICORE job instance, a storage instance is created, corresponding to the job’s working directory. In some cases you might wish to control this storage in detail, e.g. configure a special storage backend.

The working directory storages are configured using a set of properties, which is the same as for the other storage types, except for the prefix.

For example

UNICORE supports metadata management on a per-storage basis. This means, each storage instance (for example, the user’s home, or a job working directory) has its own metadata management service instance.

Metadata management is separated into two parts: a front end (which is a web service) and a back end.

The front end service allows the user to manipulate and query metadata, as well as manually trigger the metadata extraction process. The back end is the actual implementation of the metadata management, which is pluggable and can be exchanged by custom implementations. The default implementation has the following properties

By default, metadata support is enabled on all storages (except job directories).

You can disable it on a per-storage basis, see [ux_storages] for the relevant config settings.

You can also control which implementation should be used. This is done in <CONF>/uas.config.

If a file named .unicore_metadata_control is found in the base directory (i.e. where the crawler starts its crawling process), it is evaluated to decide which files should be included or excluded in the metadata extraction process.

By default, all files are included in the extraction process, except those matching a fixed set of patterns (".svn", and the UNICORE metadata and control files themselves).

The file format is a standard "key=value" properties file. Currently, the following keys are understood

The include/exclude patterns may include wildcards ? and *.

Examples:

To only include pdf and jpg files, you would use

To exclude all doc and ppt files,

To include all pdf files except those whose name starts with 2011,

UNICORE can be set up to automatically scan storages and trigger processing steps (e.g. submit batch jobs or run processing tasks) according to user-defined rules.

By default, data-triggered processing is disabled on all storages.

Explicit control is available via the configuration properties for storages, as listed in [ux_storages] Set the enableTrigger property to "true" to enable the data-triggered processing for the given storage.

To control which directories should be scanned, a file named .UNICORE_Rules at the top-level of the storage is read and evaluated. This file can be (and usually will be) edited and uploaded by the user.

The file must be in JSON format, and has the following elements:

The "IncludeDirs" and "ExcludeDirs" are lists of Java regular expression strings that denote directories (as always relative to the storage root) that should be included or excluded from the scan.

The "Rules" section controls which files are to be processed, and what is to be done (actions). This is described below.

Since shared storages are "owned" by the UNICORE server and used by multiple users, data-triggered processing requires a valid Unix user ID in order to list files independently of any actual user. Therefore the triggerUserID property is used to configure which user ID should be used (as always in UNICORE, this cannot be root, and multiuser operation requires the TSI!).

For example, you might have a project storage configured like this:

Here the scanning settings are only evaluated top-level.

For each included directory, a separate scan is done, controlled by another .UNICORE_Rules file in that directory. So the directory structure could look like this:

The top-level .UNICORE_Rules file must list the included directories. Processing the included directories is then done using the owner of that directory.

The "Rules" section in the .UNICORE_Rules file is a list of file match specifications together with a definition of an "action", i.e. what should be done for those files that match.

The general syntax is

The mandatory elements are

The following variables can be used in the Action description.

This type of action defines a script that is executed on the cluster login node (TSI node).

This type of action defines a batch job that is submitted to the resource management system of your cluster.

The Job element is a normal UNICORE job in the same syntax as used for the UCC commandline client.

This action will extract metadata from the file. The Settings element is currently unused.

The authorization process in UNICORE/X requires that nearly all operations must be authorized prior to execution (exceptions may be safely ignored).

UNICORE allows to choose which authorization back-end is used. The module which is responsible for this operation is called Policy Decision Point (PDP). You can choose one among already available PDP modules or even develop your own engine.

Local PDPs use a set of policy files to reach an authorisation decision, remote PDPs query a remote service.

Local UNICORE PDPs use the XACML language to express the authorization policy. The XACML policy language is introduced in the Guide to XACML security policies. You can also review this guide if you want to have a deeper understanding of the authorization process.

There are three options which are relevant to all PDPs:

The implementation class of this module is: eu.unicore.uas.pdp.local.LocalHerasafPDP so to enable this module use the following configuration in uas.config:

The configuration file content is very simplistic as it is enough to define only few options:

The policies from the localpdp.directory are always evaluated in alphabetical order, so it is good to name files with a number. By default the first-applicable combining algorithm is used and UNICORE policy is stored in two files: 01coreServices.xml and 99finalDeny.xml. The first file contains the default access policy, the latter a single fall through deny rule. Therefore you can put your own policies using an additional file in file named e.g. 50localRules.xml.

The policies are reloaded whenever you change (or touch) the configuration file of this PDP, e.g. like this:

This PDP allows for mixing local policies with policies downloaded from a remote server using SAML protocol for XACML policy query. This protocol is implemented by Argus PAP server Argus PAP. Please note that under the name Argus there is a whole portfolio of services, but for purpose of UNICORE integration Argus PAP is the only one required.

Usage of Argus PAP together with UNICORE policies is useful as Argus PAP allows for a quite easy editing of authorization policies with its Simplified Policy Language. It is less powerful then XACML but allows for performing all the typical tasks like banning selected users or VOs. Also if Argus is used to provide authorization rules for other middleware installed at the site (as gLite or ARC), it might be desirable to have a single place to store site-wide policies.

Unfortunately as Argus policy can not fully take over the UNICORE authorization (see the above note for details), the Argus policy must be combined with the classic UNICORE XACML 2 policy, stored locally.

The implementation class of this module is: eu.unicore.uas.pdp.argus.ArgusPDP so to enable this module use the following configuration in uas.config:

The PDP configuration is very simple as it is only required to provide the Argus endpoint and query timeout (in milliseconds).

You can use both http and https addresses. In the latter case server’s certificate is used to make the connection. Note that all localpdp.* settings are the same as in case of the default, local XACML 2.0 PDP.

Using the available configuration options, it is possible to merge Argus policies in many different ways. Here we present a simple pattern, which is good for cases when Argus is used to ban users (it was also applied to the example above):

Then Argus policy will be evaluated first. If any banning rule matches the user then it will be denied by the Argus policy. Otherwise it will be non-applicable and the local, default UNICORE policy will be evaluated. Note that if it is problematic for other (non-UNICORE) services using Argus, to remove the final fall-through permit or deny rule, then you can add such rule, but with a proper resource statement so it will be applicable only for non-UNICORE components.

Of course it is also possible to creatively design other patterns, when for instance Argus policy is evaluated as a second one.

XACML authorization policies need not to be modified on a day-to-day basis when running the UNICORE server. The most common tasks as banning or allowing users can be performed very easily using UNICORE Attribute Sources like XUUDB or Unity. This guide is intended for advanced administrators who want to change the non-standard authorization process and for developers who want to provide authorization policies for services they create.

The XACML standard is a powerful way to express fine grained access control. The idea is to have XML policies describing how and by whom actions on resources can be performed. A very readable introduction into XACML can be found with Sun’s XACML implementation.

There are several versions of XACML policy language. Currently UNICORE supports both 1.x and 2.0 versions. Those are quite similar and use same concepts, however note that syntax is a bit different. In this guide we provide examples using XACML 2.0. The same examples in the legacy XACML 1.1 format are available in xref:use_policies-11.

UNICORE allows to choose one of several authorization back-end implementations called Policy Decision Points (PDP). Among others you can decide whether to use local XACML 1.x policies or local XACML 2.0 policies. The authorization section shows how to choose and configure each of the available PDPs.

In UNICORE terms XACML is used as follows. Before each operation (i.e. execution of a web service call), an XACML request is generated, which currently includes the following attributes:

Note that the above list is valid for the default local XACML 2 and legacy XACML 1.x PDPs. For others the attributes might be different - see the respective documentation.

The request is processed by the server and checked against a (set of) policies. Policies contain rules that can either deny or permit a request, using a powerful set of functions.

Typically, the authorization policy is stored in one file. However as this file can get long and unmanageable sometimes it is better to split it into several ones. This additionally allows to easily plug additional policies to the existing authorization process. In UNICORE, this feature is implemented in the XAML 2.0 PDP.

When policies are split in multiple files each of those files must contain (at least one) a separate policy. A PDP must somehow combine result of evaluation of multiple policies. This is done by so-called policy combining algorithm. The following algorithms are available, the part after last colon describes behaviour of each:

Each policy file can contain one or more rules, so it is important to understand how possible conflicts are resolved. The so-called combining algorithm for the rules in a single policy file is specified in the top-level Policy element.

The XACML (from version 1.1 onwards) specification defines six algorithms: permit-overrides, deny-overrides, first-applicable, only-one-applicable, ordered-permit-overrides and ordered-deny-overrides. For example, to specify that the first matching rule in the policy file is used to make the decision, the Policy element must contain the following "RuleCombiningAlgId" attribute:

The full identifiers of the combining algorithms are as follows:

A common use case is to allow/permit access to a certain service based on a user’s role This can be achieved with the following XACML rule, which describes that a user with role "admin" is given access to all services.

If the access should be limited to a certain service, the Target element must contain a service identifier, as follows. In this example, access to the DataService is granted to those who have the data-access role.

By using the <Action> tag in policies, web service access can be controlled on the method level. In principle, XACML supports even control based on the content of some XML document, such as the incoming SOAP request. However this is not yet used in UNICORE/X.

Most service instances (corresponding e.g. to jobs, or files) should only ever be accessed by their owner. This rule is expressed as follows:

To get more detailed information about XACML policies (e.g. to get the list of all available functions etc) consult the XACML specification. To get more information on XACML use in UNICORE/X it is good to set the logging level of security messages to DEBUG:

You will be able to read what input is given to the XACML engine and what is the detailed answer. Alternatively, ask on the support mailing list.

This section contains the same examples as are contained in the previous section, but using XACML 1.x syntax. For more detailed discussion of each example please refer to the previous section.

Policy header with first-applicable combining algorithm.

A user with role "admin" is given access to all service.

Defining which resource access is defined with the Target element:

Allowing access for the resource owner:

XtreemFS is a distributed filesystem (see http://www.xtreemfs.org).

XtreemFS can be mounted locally at more than one UNICORE site, making it desirable to have an optimized way of moving files used in UNICORE jobs into and out of XtreemFS.

To achieve this, UNICORE supports a special URL scheme "xtreemfs://" for data staging (i.e. moving data into the job directory prior to execution, and moveing data out of the job directory after execution).

As an example, in their jobs users can write (using a UCC example):

to have a file staged in from XtreemFS.

At a site that wishes to support XtreemFS, two ways of providing access are possible. If XtreemFS is mounted locally and accessible to the UNICORE TSI, it is required to define the mount point in CONF/uas.config :

In this case, data will simply be copied by the TSI.

If XtreemFS is not mounted locally, it is possible to define the URL of a UNICORE Storage which provides access to XtreemFS

In this case, data will be moved using the usual UNICORE file transfer mechanism.

UNICORE/X can use S3, Swift or CDMI storages as backend. These storages can be configured both as a normal storage (shared or attached to target systems) and as storage backend for the StorageFactory service (see also [ux_storages])

Configuring a cloud storage as a shared storage works exactly as described in [ux_storages], you just have to make sure to use the required properties.

The following sections list the required properties for all of the supported cloud storages. Note that the prefix depends on what type of storage (shared, dynamic, TSS, job working directory) is being configured.

Compare the examples below! The authentication keys can be handled flexibly, as detailed in the next section.

There are several ways to configure the required credentials for authenticating the user to the cloud store. Two of them are done server-side (i.e. by the UNICORE administrator) and the third uses the credentias provided by the user.

UNICORE/X looks for credentials in the following order

It is always possible for the user to pass in credentials when creating the storage using the StorageFactory service. Of course this mechanism does not apply when using a cloud store for a different type of storage service.

The second option (using attribute sources) allows to configure per-user credentials, but managing everything server-side, so the user has a nice single-sign-on experience when using UNICORE.

If you use the map file attribute source, an example entry looks like this:

Last not least, the keys can also be hardcoded into the config, using the accessKey and secretKey properties.

If configured as a dynamic storage, a new directory will be created corresponding to each storage.

In the following example we configure S3 in addition to the "DEFAULT" storage type.

Configuring as a TSS storage works accordingly.