UNICORE Registry Reference Card

Functional description

The UNICORE Registry is a specially configured instance of a UNICORE/X server, providing a special service called a "Registry". This is used by clients to find required services. It is populated by the UNICORE/X servers, and the content is held up-to-date using entry lifetime mechanisms.

Daemons running

The UNICORE Registry is a single process.

Init scripts and options (start|stop|restart|...)

The service can be started with /etc/init.d/unicore-registry {start|stop|restart}.

Configuration files location with example or template

The configuration files are located in /etc/unicore/registry

• wsrflite.xml : keystore/truststore locations and passwords, gateway location, host/port, deployed web services, service persistence configuration
• uas.properties : some service container configuration (startup code, etc). AuthZ attribute source configuration
• xacml2Policies/*.xml : XACML security policies
• logging.properties : log4j logging configuration

Logfile locations (and management) and other useful audit information

The log files will be written to /var/log/unicore/registry/registry.log Logfiles are by default rolled over daily. Details can be controlled in the logging.properties file

Open ports

• the web server port, configured in the wsrflite.xml file (default: 7778).

Possible unit test of the service

Unit tests are part of the build procedure and executed automatically.

Where is service state held (and can it be rebuilt)

Service state is held in a configurable database. By default, the data is kept on the file system (using an embedded database engine). The service state is held in /var/lib/unicore/registry

Cron jobs

None

Security information

Access control Mechanism description (authentication & authorization)

Users are authenticated by the UNICORE gateway. Authorization is performed by UNICORE/X in the following way

• based in the user's identity, authz attributes are fetched from the configured sources
• based on these attributes, an XACML callout is made to check that the current operation (web service call) is allowed
• if not allowed, an "Access denied" fault is thrown

How to block/ban a user

Revoke the certificate. It is possible to ban a user by using the XACML policy check. Ie, add a rule denying access to role "banned" and assign that role to the user that should be banned.

Network Usage

A UNICORE Registry will connect to

• UNICORE gateway(s)
• AuthZ attribute services (UVOS, XUUDB, SAML-VOMS) depending on configuration

Firewall configuration

• see above for outbound connections

Security recommendations

Do not run as root.

Security incompatibilities

None known.

List of externals (packages are NOT maintained by Red Hat)

n/a

Other security relevant comments

n/a

Utility scripts

n/a

-- BerndSchuller - 18-Mar-2011