This page explains how to configure this feature as an administrator, for user-specific docs, please refer to the Use page.

Galaxy Authentication Configuration Options

Galaxy offers various methods for user authentication (aka login). All the methods share some common concepts, which are explained on this page. The method-specific configurations are explained at the following pages:

• Galaxy Username and Password
• Using 3rd party identity (i.e., social login)

The Internal Process for Authenticating a User

The following steps are followed in any code that seeks to recognize a user within Galaxy and allow access to the application:

1. The identity credential, currently the e-mail address of the user, is used to find any previously-registered user in the database.
2. Where no user exists and the login mechanism requires explicit registration, authentication fails at this point. Otherwise, a user is automatically created for previously unknown identities.
3. For conventional accounts requiring a password, authentication fails at this point if a valid password is not specified. Otherwise, an alternative mechanism for completing authentication may be invoked.
4. Upon completion of the authentication of a user’s identity, any association of that identity with the Galaxy user instance may be performed. For example, an OpenID identity may be associated with a user created for that identity.
5. Finally, the login is handled using the handle_user_login method on the GalaxyWebTransaction object, associating the user with a new session.

Authentication Related Source Code

The main controllers for user authentication are:

• User controller: lib/galaxy/webapps/galaxy/controllers/user.py;
• OIDC controller: lib/galaxy/webapps/galaxy/controllers/authnz.py

The related managers are:

• UserManager;
• AuthManager (relates to authentication agains local database, LDAP, and PAM);
• AuthnzManager (relates to OIDC-based authentication).

And the primary related models are:

• User;

• OIDC:

  • UserAuthnzToken;

Database Tables

The database employs a galaxy_user table which records the details of all registered users, and this table is exposed to the code through the User abstraction found in lib/galaxy/model/mapping.py. Each logged-in user is assigned a session which references the user in the galaxy_session table (exposed via GalaxySession).

User information from external sources, such as OIDC, is found in peripheral tables such as:

• Tokens are stored in UserAuthnzToken table;
• implementation-specific (transient) information are stored in peripheral tables such as: PSAAssociation, PSACode, PSANonce, and PSAPartial.