Skip to content
This repository has been archived by the owner on Mar 12, 2021. It is now read-only.

Documentation

ccacciari edited this page Jan 7, 2019 · 25 revisions

User documentation

http://eudat.eu/services/userdoc

Authentication

The B2SAFE service relies on the authentication mechanisms supported by iRODS. Moreover, it is possible to enable the support for oauth2 token, deploying and configuring the PAM OAuth2 module. As described in the related documentation, the module follows this approach: it assumes that an oauth2 token is available to the user. The user have to login to iRODS using the PAM authentication and replacing the password of the local account with the oauth2 token of the global account. Then B2SAFE queries, server-side, the OAuth2 provider and get the attributes to map the global account to the local one.

Authorization

B2SAFE supports unix-like ACLs on the stored data.

The ACLs on iRODS rules are enforced applying the rule EUDATAuthZ(*user, *action, *target, *response).
For example:

acPreProcForExecCmd(*cmd, *args, *addr, *hint) {
    if (*cmd != "authZmanager.py") {
        EUDATAuthZ("$userNameClient#$rodsZoneClient", *cmd, *args, *response);
    }
}

The above code, placed in /etc/irods/core.re, will enforce the permission to execute external commands according to the assertions defined in the file authZ.map.json described here.
By default the B2SAFE relies on this mechanism to filter the access to the python client for the operations related to the PIDs creation, update and delete. It is possible, for performance reasons (https://github.com/EUDAT-B2SAFE/B2SAFE-core/wiki/Documentation#performance), to disable it, setting the parameter authzEnabled to "false" in the local.re.

Performance

We can distinguish roughly two main tasks that have an impact on the performance: the data transfer and the PID registration. The former is heavily influenced by the bandwidth available for the transfer, the computing power available for the checksum calculation, which is mandatory to spot data corruption, the number and the average size of the objects and the back-end storage speed in terms of read and write operations.
While the latter is more dependent on the number of "atomic" operations involved in a single PID creation, although the connection speed between the PID registry and the B2SAFE service and the PID registry response time are important also.
Therefore while it does not make sense here to provide figures for the data transfer performance, we think that it could be useful for the PID registration, even if they are just an hint.

Reference Options number of PIDs/minute (order of magnitude)
1 default: rules' ACLs enforcement and python client 10^1
2 without rules' ACLs enforcement (10^2) x 2
3 pure PID creation via PID service REST API (B2HANDLE) (10^2) x 4
  1. This is the default when you deploy the B2SAFE package.
  2. This option is enabled by the parameter authzEnabled (=False) in the local.re.
  3. This option is just for comparison, because it implies a PID creation invoked outside the B2SAFE, relying only on the B2HANDLE library.

PID service (HSv8)

The current PID registry system in EUDAT is based on the HANDLE system version 8 (HSv8). And B2SAFE relies on the B2HANDLE library to interact with it:

  • install b2handle library

  • create private/public keys, certificates and interacts with the PID registry administrator to get the public key uploaded (see here)

  • see the configuration of the credentials here

  • test epicclient2.py:

/opt/eudat/b2safe/cmd/epicclient2.py os /opt/eudat/b2safe/conf/credentials create www.test.com

Experimental features