EUDAT-PRACE pilot for cross-infrastructure access to resources

State of art in current production infrastructures

Use-case: To automatically provision accounts on EUDAT from PRACE.

B2ACCESS – B2STAGE/B2SAFE integration in EUDAT

The current official EUDAT implementation uses the following steps:

The user registers in B2ACCESS (and accesses it) using one of these different types of credentials:
- SAML IdP,
- social ID,
- local username/password,
- X.509 (long living cert signed by IGTF approved CA)
B2ACCESS issues X.509 short living cert signed by its internal CA
- Expected to be replaced with RCauth
- However. PRACE is not expected to accept RCauth
The couple of scripts running on the resource (B2STAGE/B2SAFE service) periodically get users from B2ACCESS, provision accounts and map DN from the issued certificate to these accounts.
The user accesses the resource using the EUDAT certificate

Figure 1. EUDAT B2ACCESS - B2STAGE/B2SAFE integration

The mapping of the (external/DN) user name to local (iRODS) user is configured in role_map.json file. The file allows mapping one or more B2ACCESS/Unity groups (organizations) or users to iRODS account. The names of groups or user ids must be explicitly mentioned in that file. This type of mapping means, that normally multiple users are mapped to single iRODS account and share their data within the defined group.

User management and AAI in PRACE

User accounts are kept in a central LDAP and local accounts on PRACE nodes are provisioned by this database directly or by synchronizing it offline. The users are authenticated by X.509 (long living) certificates signed by IGTF approved CA. In particular, B2ACCESS X.509 short living certificates will not be widely accepted by PRACE nodes.

There is deisaUserProfile attribute in the LDAP schema. This attribute with value “EUDAT” is provided to users who indicated a consent that their user information may be shared between PRACE and EUDAT.

PRACE – EUDAT AAI integration

Figure 2. Overview of the integration components

PRACE LDAP -> B2ACCESS synchronization

Users from PRACE LDAP with deisaUserProfile set to “EUDAT” must be imported to B2ACCESS. While this import some LDAP attributes shall be converted to B2ACCESS groups, also all these users probably shall belong to “PRACE” group. In this way we distinguish PRACE users from anyone with IGTF certificate who can setup an B2ACCESS account.

Technically, this component is implemented in Python as a proxy between the PRACE LDAP (using LDAP interface) and B2ACCESS (using Unity HTTP API as interface). This component must be run periodically (cron job) under EUDAT control (suggested place is the B2ACCESS machine), as with the current Unity implementation needed API functions require an account with full administration rights. On the other side only limited (read-only) access to LDAP is necessary.

The script (prace_eudat_users_sync.py) works as follows:

Collect selected users from PRACE LDAP
For each collected PRACE user:
1. Create Unity entity with x500 name identity equal to PRACE user DN (if not already exist)
2. Add the entity to PRACE Unity group (if not already added)
For each Unity entity in PRACE group:
1. Remove the entity from this group if it is not within collected PRACE users

As the result all and only PRACE users with deisaUserProfile set to “EUDAT” have B2ACCESS accounts and belong to PRACE group, which also implies access to other EUDAT services.

B2ACCESS – B2STAGE/B2SAFE integration

Two different integration methods are implemented.

Modification of the existing mechanism

The modified (remote_users_sync.py) script is run from cron on B2STAGE and provisions user's account. Besides EUDAT DN (one from the certificate generated by B2ACCESS) the script maps also DN from the X500Name identity which is certificate used to authenticate the user against B2ACCESS (in this case: the “PRACE” certificate), e.g:

[[     
    "/C=DE/L=Juelich/O=FZJ/OU=JSC/CN=a7f7c4b5-7005-4af6-b346-b87f6e8ba442/CN=226",     
    "/C=PL/O=GRID/O=PSNC/CN=Michal Jankowski"   
]]

Technical details:

B2ACCESS DN is computed by the script as: <CA DN>,CN=<user persistent id>,CN=<user id>, where <CA DN> is a config parameter, <user persistent id> and <user id> are obtained from B2ACCESS using HTTP API
The external DN is obtained from B2ACCESS using HTTP API, it occurs in element identities in JSON resulted from calling path /entity/{entity id}, e.g.

"identities":[

        {"typeId":"x500Name", 
         "value":"CN=Michal Jankowski,O=PSNC,O=GRID,C=PL", …},

        {"typeId":"persistent",
         "value":"a7f7c4b5-7005-4af6-b346-b87f6e8ba442" …}]

New mechanism

Authentication and mapping DN of the initiator of incoming gridFTP request to iRODS user is done by B2STAGE software (gridmap_iRODS_callout) implemented by EUDAT. This solution introduces a additional callout to B2STAGE code: an external application is called prior the authentication and mapping. The application gets the DN as a parameter, so it may perform online verification against B2ACCESS of this single user.

The application is implemented as a Python script (irods_user_sync.py) and works as follows:

Get user (entity) info and groups from Unity
If the user doesn’t belong to any of locally accepted B2ACCESS groups, remove the user from local (iRODS) groups that are maps of B2ACCESS groups (e.g. from PRACE group) and exit.
If the user doesn’t have a local iRODS account, create it and add DN mapping to that account. The local username may be concatenation of some string and B2ACCESS id or persistent id (configurable).
Add the user to local groups according to group map configuration.

Demonstrator

The demo is available for users added to the test LDAP, in order to try it please contact: jankowsk@man.poznan.pl

Test B2ACCESS user console: https://b2access.eudat.psnc.pl:2443/home/home
Test B2STAGE/iRODS site: eptest.eudat.psnc.pl

Demonstrator workflow

1.	Group "PRACE" is empty on B2ACCESS and there is no user like "Michal Jankowski" in B2ACCESS
2.	User "/C=PL/O=GRID/O=PSNC/CN=Michal Jankowski" cannot access EUDAT resource at gsiftp://eptest.eudat.psnc.pl
3.	There is no local user account mapped to "/C=PL/O=GRID/O=PSNC/CN=Michal Jankowski" on eptest.eudat.psnc.pl.
4.	Users with attribute deisaUserProfile set to “EUDAT” are selected from PRACE LDAP. The same selection is done by prace_eudat_users_sync.py script, that synchronizes PRACE LDAP and B2ACCESS. Normally the script is called periodically (e.g. hourly), but for the demo it may be run manually by the admin.
5.	After the script run, the user "/C=PL/O=GRID/O=PSNC/CN=Michal Jankowski" appear in B2ACCESS and group "PRACE" contains PRACE users.
6.	User "/C=PL/O=GRID/O=PSNC/CN=Michal Jankowski" can access EUDAT resource at gsiftp://eptest.eudat.psnc.pl
7.	Local user account provisioning and grid mapping are done automatically on user login.
8.	Attribute deisaUserProfile with value “EUDAT” is removed from user "Michal Jankowski" in PRACE LDAP.
9.	As the result of prace_eudat_users_sync.py script run the user is removed from PRACE group in B2ACCESS (but not completely from the service).
10.	User "/C=PL/O=GRID/O=PSNC/CN=Michal Jankowski" cannot access EUDAT resource at gsiftp://eptest.eudat.psnc.pl
11.	The local account still exists, but the user is removed from the grid mapping.