Authentication

Return to the main index.

Use of the Default Encrypted Password.

Each iRODS server has a server configuration file (iRODS/server/config/server.config) which stores information (location, login, etc.) about the iCAT database server (PostgreSQL) and rules sets, etc. used.  This file stores the iCAT database password in an encrypted form and allows the server access to the iCAT database whether it is local to that server or if it is located on another server (resource) in the system (zone).  Note: RCAT is sometimes mentioned in the comments in the server.config file and also in some places within the ICAT database – RCAT is a deprecated name for iCAT.  An iRODS system (a zone) stores iRODS user names and passwords (in an encrypted form) in the iCAT database.
On a client machine (which may or may not run an iRODS server) the .irods/.irodsEnv file contains information about the environment:

• Default storage resource name.
• Home directory in iRODS.
• Current directory in iRODS.
• Account name.
• Zone.

Also on the client machine the .irods/.irodsA file contains the encrypted password for the account described in .irods/.irodsEnv.  The .irods/.irodsEnv file may be created or copied by hand but the .irods/.irodsA file is created using the 'iinit' which asks for the password and stores it in the .irods/.irodsA file.
Plain-text passwords are therefore not stored but it would be possible to decrypt the password given the iRODS source code – iRODS does not claim this to be high-grade encryption.
iRODS uses a challenge / response protocol to confirm that the user has the correct password, without sending it on the network.

When running rules the iRODS server ‘remembers’ that you authenticated and then recreates that context in the irodsReServer (for delayed rules). For immediate rules (in the irodsAgent), the client context is your irods user.

Use of the Grid Security Infrastructure (GSI).

iRODS supports GSI (Grid Security Infrastructure) as an authentication method.  Both clients and servers need to be built with the GSI option when using the irodssetup script and you also you need to provide details of the globus location, etc.

iRODS servers run as a non-root user, (they don't have access to the private key and can't use the host certificate) so use whatever key is specified in the GSI environment.  The GSI environment must be set up prior to starting a GSI-enabled iRODS server (using irodsctl start).  The environment can be setup either by:

• Editing the scripts/perl/irodsctl.pl file to set environment variables X509_CERT_DIR, X509_USER_CERT and X509_USER_KEY to specify the location of your choice for Certificate-Authority certificate directory, the server's (GSI user) certificate and certificate key, respectively.
  
• Running grid-proxy-init. Users can select GSI by setting irodsAuthScheme=GSI in their .irodsEnv files.

iRODS users can authenticate with GSI and can also now set the environment variable SERVER_DN to authenticate the server via the GSI system (perform mutual authentication).  Even when GSI is set up users can still use the iRODS password system if desired.

Use of Kerberos.

Kerberos is now available for iRODS, it handles the authentication of users and the particular iRODS system (zone) is regarded as a service in Kerberos parlance.  The following notes are additional to the description provided in the iRODS link above.

Clearly a Kerberos realm with which to interact, must be available.

About the iRODS system:

• The iRODS server machine must have the Kerberos client software installed.
• The iRODS service must be registered by the administrator of the Kerberos Key Distribution Center (KDC).  The KDC consists of an Authentication Server (AS) and a Ticket Granting Service (TGS).
• The iRODS machine must have the keytab file (containing the secret iRODS service key) installed - this file is provided the Kerberos administrator.
• For an iRODS user there are two identifiers: the iRODS username and the Kerberos user principle - the latter should be added to the iRODS user name using iadmin moduser and adding the principle name as the DN field.

• The Kerberos client software installed.

• The keytab file (containing the secret user key) installed - again this file is provided the Kerberos administrator.
• The irodsAuthSchem in the .irodsEnv file should be set to Kerberos.
• Running kinit on a client will usually gets a Ticket Granting Ticket (TGT) - but in this case iRODS suggests it gets an actual ticket for the iRODS service.

 This will not work with the iRODS web browser.

Future Use of Shibboleth

Shibboleth is being integrated for a web based environment (also see here and here).

The Shibboleth SP is currently only implemented in C++ as a module for Apache, IIS, and NSAPI.

• iRODS could be a Shibboleth-protected resource and needs to provide Service Provider (SP) functionality.  It would redirect to a WAYF (Where Are You From) function and then use the appropriate Identity Provider (IdP).  The SP would then have to get the necessary assertions from the IdP to log the user on.  This would allow a user to logon using their home login details and would give them access to a "parallel" account on iRODS (similar to the arrangement with Kerberos). It is assumed that the iRODS cross zone functionality would act as it does now.
• Shibboleth could be embedded much more deeply in iRODS so that it handles logins in any Zone and replaces some of the iRODS inter-zone interactions.  This requires further consideration.