Native iRODS user mapping (feature)

[vladimir-mencl-eresearch]

Hi Roberto,

I am looking at adding a feature that would allow users to authenticate with "native" DN mapping that iRODS already has.

I.e., instead of having to add the DN of the server to every iRODS user account, users would only have the DNs of their user certificates specified as the external identities of their iRODS accounts.

We already have this in our existing setup - where we are using Griffin (http://code.google.com/p/datafabric-griffin/) as the GridFTP server. But we are aiming to replace Griffin with your DSI module - and that's why I'm planning to add this feature.

I think I have all of the individual pieces ready (as prototypes of the desired functionality) and just need to put it all together (and implement the code linking the pieces together).

• For the GridFTP-DSI to iRODS authentication, I would use a variant of the rcConnect call where the client authenticates as a rodsAdmin user (rods) and specifies to act on behalf of a particular user.
  • (ProxyUserName="rods", ClientUserName=iRODS_handle->user)
  • For this to work, the GridFTP server DN would have to have access to the "rods" iRODS account.
• Instead of having to maintain a grid-mapfile of user DNs to iRODS user names on the GridFTP server, I would implement a mapping callout function that the GridFTP server would use.
  • The mapping function would essential do an iquest "select USER_NAME where USER_DN = '/C=XX/O=YYYY/CN=ZZZZ'"
  • As an extra to support our workflow, I would also add a configurable option to invoke an iRODS server-side script (via iexec) if the mapping is not found - and try the lookup again after executing the script.
  • We have a script that automatically creates accounts on first access - and is invoked by the iRODS server in GSI logins when no mapping is found (via the acGetUserByDN iRODS rule).
  • This feature would mimick the same behavior - as we are not doing a true GSI with the user certificates, the explicit invocation would be the best equivalent for triggering the rule / the script.

How does this sound to you?

I would like to get your feedback before I start implementing this - so that it does not come to you as a surprise - and does not clash with your vision on where this code should be evolving.

And by having this recorded in github, we can also use this github issue as the discussion space for this feature.

Of course, this whole feature would be a configurable option - and the existing workflow would be still supported.

Please let me know what you think.

Cheers, Vlad

[muccix]

Hi Vlad,

that sounds good!

From my side, I have just one constraint: since the DSI is currently used by different communities, it is important that this new feature will be optional (as you actually wrote ;) ).

I'm looking forward to seeing some new code!

Cheers, Roberto

[muccix]

Hi Vlad,

thanks in advance for this huge contribution!

I will test everything in the next days. In particular I am keen to test the Globus gridmap callout module!

Question: since worked a lot on the DSI, would you mind if I add you name as author of the class?

I will get back to you soon.

Cheers, Roberto

[vladimir-mencl-eresearch]

Hi Roberto,

Thanks, all fine with me adding my name to it.

Cheers, Vlad