Skip to end of metadata
Go to start of metadata

Date: August 29th, 2019

Several of our (pilot) customers are using iRODS and wanted to connect it to our AARC BPA based platform. On August 28th, we had a meeting sharing progress, and these notes might be interesting to others wondering how to use federated identity and/or connect iRODS to PAM etc. When you read this, of course, things have probably changed/progressed...

  • "the AAI flow to synchronize the CO attributes from SCZ to iRODS iCAT: we created a CO group in SBS (a COmanage MMS alternative) and we propagated the group and the members to the iCAT through the SCZ LDAP and the local LDAP (dedicated to iRODS service). It works. The synchronization between the local LDAP and iCAT is done through a python script running as a cron job every 5 minutes. The python script talks with iRODS using the iRODS python api and the privileges of the iRODS admin user. It works fine, however for the PoC we aim to improve it, defining a policy for the deletion of users/groups. The automatic deletion of users and groups in iRODS should be prevented because in case of mistakes, iRODs has no way to roll back to a previous consistent state. So the improvement for the PoC would be to replace the current automatic deletion implemented in the script with a notification to the iRODs admins, who can then decide what to do (asking the PI, moving the data to another user, etc.). Later it is desirable to implement the possibility to save the user's related metadata so that it is possible to go back to a safe state in case of errors.

  • the authentication for web based tools. Metalnx was used as a web tool. Metalnx relies on iRODS for users and groups, so the propagation of the CO attributes allows to log in with Metalnx using the same identity provided to SCZ. We have single identity between SCZ and iRODS/Metalnx. However SCZ does not propagate the password. Hence a self-provisioning service has been set up to enter manually a password for the SCZ identity. The password is stored on a local LDAP (but not the one used for the CO attributes). It works. However to achieve SSO, supporting federated identity via SAML protocol is not possible with the current code. It would be necessary to change both iRODS and Metalnx code.
    The amount of work required is not clear, but could be important.

  • the authentication for non-web tools. In this case the approach based on SAML has been demonstrated using the SSH service. The SSHD has been configured to use the PAM web SSO module. When the user log in with the SSH client, she triggers the PAM web SSO on the server side, which generates a PIN code and nounce. Then it sends them to the SAML SP service (implemented here with https://simplesamlphp.org) and at the same time, it sends the "URL+nounce" to the SSH client, as part of a PAM conversation. the SSH client prints it on the screen and the user copy the URL+nounce to a web browser and visualize the login page of the SAML SP. Once the user clicks on the login button, she is redirected to the SAML IdP (again implemented here with https://simplesamlphp.org), where she can log in with her IdP credentials. If successful, she is redirected back to the SAML SP web page, where she can read the PIN code. She copies it to the screen where the SSH client is waiting her input and logs in. It works.

    The plan is to implement the same approach with iRODS. However the iRODS PAM code does not allow to print the "URL+nonce" when the user issues "iinit", therefore it is not straightforward to adopt the SAML approach.
    It is possible to check how the PAM works in iRODS in this way:

    - configure properly the PAM authentication according to the iRODS documentation and in particular setting up the following file:
    # cat /etc/pam.d/irods
    auth required pam_env.so
    auth required pam_exec.so debug stdout /etc/irods/challenger.sh
    auth sufficient pam_unix.so
    auth required pam_deny.so

    Where challenger.sh is just a bash script printing a line of words: "Would you like to authenticate?". And then using the pamAuthCheck utility:

    $ /usr/sbin/irodsPamAuthCheck claudio debug
    myPassword
    password bytes: 11
    retval_pam_start: 0
    null_conv: num_msg: 1
    null_conv: msg index: 0
    null_conv: msg_style: 1 -> PAM_PROMPT_ECHO_OFF
    null_conv: msg: Password:
    null_conv: num_msg: 1
    null_conv: msg index: 0
    null_conv: msg_style: 4 -> PAM_TEXT_INFO
    null_conv: msg: Would you like to authenticate?
    null_conv: num_msg: 1
    null_conv: msg index: 0
    null_conv: msg_style: 1 -> PAM_PROMPT_ECHO_OFF
    null_conv: msg: Password:
    retval_pam_authenticate: 0
    Authenticated

  • So the message "Would you like to authenticate?" is really provided back from the PAM module to the pamAuthCheck code, but then it is ignored by it, just showed in debug mode.
    In conclusion we see only two approaches to overcome the issue:

    1) developing a security iRODS plugin, which implements a client-server architecture that allows a special version of "iinit" (a wrapper around the original one) to talk with the iRODS server on a dedicated channel and port, outside the core authentication procedure. This is the approach followed by the team which has developed the openID plugin for iRODS. The benefit of this approach is that it is loosely coupled with the iRODS core components and thus less affected by future changes. The drawback is that it is complex and would add an important overhead to the iRODS configuration.
    2) developing a patch to the "iinit" command that supports a PAM conversation, allowing to print the messages sent back from the PAM module to the client. The benefit of this approach is that it rely on the standard iRODS configuration. The drawback is that every changes to the core could affect the patch, hence it would be really important that the patch is adopted and included in the iRODS official code.

  • We decided to go for the second option. We will check the iinit code and verify if it possible and how much complex it is. Once we achieve the result for the icommands, then we should check if it is possible to replicate the same approach with the API (in particular the python API). Therefore we will focus now on the support of the PAM web SSO for the CLI, not for the web based interfaces."


  • No labels