User, Role, Group, Quota, and Authentication managment

Updated: PURL: gxy.io/GTN:S00027

Tip: press P to view the presenter notes | Use arrow keys to move between slides

1 / 25

Presenter notes contain extra information which might be useful if you intend to use these slides for teaching.

Press P again to switch presenter notes off

Press C to create a new window where the same presentation will be displayed. This window is linked to the main window. Changing slides on one will cause the slide to change on the other.

Useful when presenting.

How does Galaxy manage users and groups?
How can I assign Quotas to specific users/groups?
How should I manage groups vs roles
What authentication methods are available?
How is dataset privacy managed?
Authentication Systems, what is available and how can I enable it?

2 / 25

Learn the Galaxy user/group management and assign Quotas.
Understand the Role Based Access Control (RBAC) of Galaxy.

3 / 25

Users

4 / 25

Users

User Control

option	description
`require_login`	Prevent anonymous access.
`show_welcome_with_login`	Show welcome page next to login page.
`allow_user_creation`	Allow user registration. When False, admins must create users; often coupled with `require_login`.
`allow_user_dataset_purge`	Users can purge (permanently delete) their datasets.
`api_allow_run_as`	List of email addresses of API users who can make calls on behalf of other users.
`expose_dataset_path`	Users to see the full path of datasets via the "View Details" option in the history.

options in galaxy.yml

5 / 25

These options let you control user login.
For example, are anonymous users permitted?
Are users able to register themselves?
Are users able to purge datasets themselves?
All of these are questions you will need to consider.
The API allow run as option can be useful if you have an external system submitting jobs to Galaxy on behalf of your users.

User Activation

Require verification that a user's email is real. You must enable SMTP first.

option	description
`user_activation_on`	Require users to click link in email before running jobs.
`activation_grace_period`	Time (hours) that a user can 'explore' Galaxy before activation lockout.
`inactivity_box_content`	Message provided to non-activated users.
`email_domain_blocklist_file`	Defines domains in XXX.YYY format that will be rejected as user emails.

options in galaxy.yml

6 / 25

Whenever a user registers, user activation settings control how this process happens
If you want to require activation they cannot run tools until they receive the confirmation email
If you want to prevent users registering from specific domains

Admin Control

option	description
`admin_users`	Comma-separated list of admin users' emails.
`allow_user_deletion`	Admins can delete users.
`allow_user_impersonation`	Admins can become other users. Great for debugging / user assistance.
`bootstrap_admin_api_key`	Admin super-key allows many API admin actions without having a real admin user.

options in galaxy.yml

7 / 25

In the ansible galaxy training, you set the admin_users variable to define an admin email
User impersonation is a very commonly used feature
It allows admins to debug issues in their users' histories
A bootstrap api key cannot be used for every task an admin API key can be used for
This is because it is not tied to an individual user

User Privacy

option	description
`expose_user_name`	Users can view other registered usernames.
`expose_user_email`	Users can view other registered emails.
`new_user_dataset_access_role_default_private`	Newly created datasets are private to the creating user.

options in galaxy.yml

8 / 25

These options control if the username or email are shown as a dropdown in the sharing menus
The option "new user dataset access role default private" is important
By default when users share by link, all datasets are public
When you set this option, datasets are private, even though the history is shared via link
Users will complain when it doesn't work, and have to be educated to click the appropriate buttons

Roles and Groups

9 / 25

Roles and Groups

Role Based Access Control (RBAC)

Admin can:

create roles (each user automatically has their own 'private' role)
create groups
assign roles to groups
assign users to groups
assign groups to roles
assign users to roles
assign permission sets to roles
assign permission sets to groups

10 / 25

Galaxy uses RBAC for permissions in many places
Roles can be created, and assigned permissions
Roles and groups behave similarly, grouping users together and granting permissions

Dataset Roles

manage permissions

Users who have associated role on a dataset can manage the roles associated it.

access

Users having associated role can use/view/download a dataset for analysis. Users must have every role associated with a dataset in order to access it

new_user_dataset_access_role_default_private (galaxy.yml)

When this is set, datasets are private by default.

User_roles

11 / 25

The manage permission controls which accounts can manage permissions of datasets
Access permission is those who can see and work with the data
These can be controlled in the permissions menu of datasets
Or more generally at the history level
Users must have every role listed in order to access that dataset
This leads to the odd case where users wish to share with multiple groups
But by adding more roles, it becomes unavailable to everyone

Library Roles

access library: Restrict access to this library to only users having associated role
manage library permissions: Users having associated role can manage roles associated with permissions on this library item
add library item: Users having associated role can add library items to this library item
modify library item: Users having associated role can modify this library item

Library_roles

12 / 25

Access library permits users with any of the listed roles to access the library
No roles means a public library
Generally the last three are set to the same values, unless you have complicated requirements
In the library management, someone with any subset of the roles listed may make changes
This is very different from dataset permission management, where users must have every role

Quotas

13 / 25

Quotas

Used to control user disk usage.

option	description
`enable_quotas`	Enable enforcement of quotas. Quotas can be set from the Admin interface (under Data).

Must create quotas in admin interface before any quota will be enforced, otherwise 'unlimited'

Amounts:

Examples: "10000MB", "99 gb", "0.2T", "unlimited"
= / + / -

Default for user class:

None (No)
Unregistered Users
Registered Users

or associated with Groups or Users

options in galaxy.yml

14 / 25

You can enable quotas in your galaxy.yml file
When the user has more data than their quotum permits, they are prevented from starting new jobs.
many sites setup a "quote increase request" form, to let users request increases for specific, temporary projects

Quota Details

Quotas can be set for Users, or all users of a Group
But it is not a "group quota"
The quota is applied to individual users

Storage

Quotas are stored in the DB tables galaxy_user, galaxy_group, and quota

15 / 25

Quotas can be set for Users or Groups
But it is applied individually, as users may receive multiple quota changes
E.g. a user working for two groups, might receive two different quota increases

Quota Automation

There is currently no quota automation.
Some individuals have written their own quota automation but it is quite ugly (usegalaxy-eu/quota-sync)
Could be nicer with a lot of work
Quotas are like group/user management: not managed by files, only within UI/API

16 / 25

Quotas can be managed through the API
Some people want to automate this process, but it needs more work.

Authentication Systems

17 / 25

Authentication Systems

LDAP / AD

Galaxy can be configured to use LDAP or Active Directory for authentication
There is a config file named config/auth_conf.xml
User login then triggers an LDAP search for the user
- (optional) Galaxy binds with some bind credentials
- Searches for the user DN
- Re-binds with the user DN and password
- If the user is found, they are logged in

18 / 25

LDAP and Active Directory can be used as an authentication method
This is done through the auth_conf.xml file
When the user logs in, the LDAP server is queried for the user

Shibboleth, CAS

Many alternative authentication systems are widely used at universities and organisations
Galaxy itself does not natively support these systems
However, you can use a proxy to authenticate users
nginx and apache have modules for both of these methods

19 / 25

Shibboleth and CAS are commonly used at some universities
While Galaxy does not natively support these, you can use a proxy to authenticate users
Nginx and apache both support this

OIDC

Galaxy can be configured to use OpenID Connect for authentication
There are two configuration files:
- config/oidc_backends_config.xml
- config/oidc_config.xml
Supports a variety of providers:
- Google
- Custos
- Globus
- ORCID
- LS Login (Elixir AAI)
- KeyCloack

20 / 25

OIDC is a common authentication method
There are two configuration files required for this
Galaxy supports a variety of providers
OIDC means you as an administrator don't have to worry about validating the account, or storing passwords

Built in Authentication

Galaxy has it's own authentication system
Enabled by default

option	description
`password_expiration_period`	Days before requiring a user to change password. (NIST recommends not requiring password changes.)
`session_duration`	Minutes before invaliding a user's session, requiring re-login.

options in galaxy.yml

21 / 25

Galaxy has it's own authentication system
There are some options are related to IT security policies
Check with your local IT authority for best practices for your organisation
Please consider not setting a password expiration period, as NIST recommends against it

Others (`REMOTE_USER`)

For all other authentication systems
If your authentication system provides a username in some secure way to the webserver
Then you can use it to authenticate users
The webserver must set the REMOTE_USER header
Galaxy will trust this header

22 / 25

If you use a different authentication system than one previously mentioned
and your users are authenticated in some manner through your webserver/proxy
Then you can take advantage of REMOTE_USER authentication
It is a very simple authentication method, the webserver sets a header, and galaxy implicitly trusts it.

Remote User (Security)

If you have local users on the Galaxy head node
Then please set remote_user_secret
This will send an additional secret header to Galaxy that will be validated
Otherwise local users can curl your Galaxy server, and impersonate any user.

23 / 25

An important aspect for security is that if you have local users on the Galaxy head node
Then you should set the remote_user_secret option, to prevent them impersonating other users

Galaxy has a powerful user and group managment system that can be utilized for Quota management.

24 / 25

Thank You!

This material is the result of a collaborative work. Thanks to the Galaxy Training Network and all the contributors!

Author(s)	Nate Coraor Björn Grüning Helena Rasche
Reviewers

Tutorial Content is licensed under Creative Commons Attribution 4.0 International License.

↑, ←, Pg Up, k	Go to previous slide
↓, →, Pg Dn, Space, j	Go to next slide
Home	Go to first slide
End	Go to last slide
Number + Return	Go to specific slide
b / m / f	Toggle blackout / mirrored / fullscreen mode
c	Clone slideshow
p	Toggle presenter mode
t	Restart the presentation timer
?, h	Toggle this help

User, Role, Group, Quota, and Authentication managment

question Questions

objectives Objectives

Users

User Control

User Activation

Admin Control

User Privacy

Roles and Groups

Role Based Access Control (RBAC)

Dataset Roles

Library Roles

Quotas

Quotas

Quota Details

Quota Automation

Authentication Systems

LDAP / AD

Shibboleth, CAS

OIDC

Built in Authentication

Others (REMOTE_USER)

Remote User (Security)

keypoints Key points

Thank You!

question Questions

Help

Others (`REMOTE_USER`)