|
|
## User documentation
|
|
|
http://eudat.eu/services/userdoc
|
|
|
http://eudat.eu/services/userdoc (not updated yet)
|
|
|
|
|
|
## Authentication
|
|
|
The B2SAFE service relies on the [authentication mechanisms supported by iRODS](https://docs.irods.org/master/manual/authentication/). However there is a preference for the GSI scheme, since it is used for the integration with other EUDAT services, like [B2ACCESS](https://eudat.eu/services/b2access) and MyProxy.
|
... | ... | @@ -18,11 +18,38 @@ For example: |
|
|
}
|
|
|
}
|
|
|
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](https://github.com/EUDAT-B2SAFE/B2SAFE-core/wiki/Python-script-configuration).
|
|
|
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_] [1].
|
|
|
|
|
|
The aforementioned ACLs can be associated to roles, exploiting the role based approach described in the [readme](https://github.com/EUDAT-B2SAFE/B2SAFE-core/blob/master/scripts/authN_and_authZ/README.md).
|
|
|
|
|
|
## [Typical workflows](https://github.com/EUDAT-B2SAFE/B2SAFE-core/wiki/Workflows)
|
|
|
|
|
|
## Performance
|
|
|
|
|
|
## PID service (EPIC, HSv8) |
|
|
\ No newline at end of file |
|
|
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.
|
|
|
<table>
|
|
|
<tr><th>Reference</th><th>Options</th><th>number of PIDs/minute (order of magnitude)</th></tr>
|
|
|
<tr>
|
|
|
<td>1</td><td>default: rules' ACLs enforcement and python client</td><td>10^1</td>
|
|
|
</tr>
|
|
|
<tr>
|
|
|
<td>2</td><td>replacing the python client with the CURL plugin</td><td>10^2</td>
|
|
|
</tr>
|
|
|
<tr>
|
|
|
<td>3</td><td>without rules' ACLs enforcement</td><td>(10^2) x 2</td>
|
|
|
</tr>
|
|
|
<tr>
|
|
|
<td>4</td><td>pure PID creation via PID service REST API (B2HANDLE)</td><td>(10^2) x 4</td>
|
|
|
</tr>
|
|
|
</table>
|
|
|
|
|
|
1. This is the default when you deploy the B2SAFE package.
|
|
|
2. This option is enabled by the parameter _msiCurlEnabled_ in the rule set [_local.re_] [1].
|
|
|
3. This option is enabled by the parameter _authzEnabled_ (=False) in the [_local.re_] [1].
|
|
|
4. This option is just for comparison, because it implies a PID creation invoked outside the B2SAFE, relying only on the [B2HANDLE library](https://github.com/EUDAT-B2SAFE/B2HANDLE).
|
|
|
|
|
|
## PID service (EPIC, HSv8)
|
|
|
|
|
|
|
|
|
[1]: https://github.com/EUDAT-B2SAFE/B2SAFE-core/wiki/Rule-set-configuration "local.re" |
|
|
\ No newline at end of file |