State of art in current production infrastructures

B2ACCESS – B2STAGE/B2SAFE integration in EUDAT

The current official EUDAT implementation uses the following steps:

  1. The user registers in B2ACCESS  (and accesses it) using one of these different types of credentials:
  2. B2ACCESS issues X.509 short living cert signed by its internal CA
  3. 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.
  4. 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:

  1. Collect selected users from PRACE LDAP
  2. 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)
  3. 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:

  1. 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
  2. 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:

  1. Get user (entity) info and groups from Unity
  2. 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.
  3. 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).
  4. Add the user to local groups according to group map configuration.

Resources

  1. Unity IDM documentation
  2. Unity IDM GitHub
  3. B2STAGE GridFTP GitHub

Status

PRACE LDAP -> B2ACCESS script:

B2ACCESS -> B2STAGE ”old” mechanism:

B2ACCESS -> B2STAGE ”new” mechanism: