User, Role, Group, Quota, and Authentication managment

Contributors

Author(s)

Nate Coraor Björn Grüning Helena Rasche

Questions

• 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?

Objectives

• Learn the Galaxy user/group management and assign Quotas.

• Understand the Role Based Access Control (RBAC) of Galaxy.

Users

Speaker Notes

Users

User Control

.footnote[.center[options in galaxy.yml]]

Speaker Notes

• 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.

.footnote[.center[options in galaxy.yml]]

Speaker Notes

• 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

.footnote[.center[options in galaxy.yml]]

Speaker Notes

• 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

.footnote[.center[options in galaxy.yml]]

Speaker Notes

• 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

Speaker Notes

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

Speaker Notes

• 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

.left-column50[ 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. ]

.right-column50[.middle[.image-90[ ]]]

Speaker Notes

• 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

.left-column50[

• 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 ] .left-column50[.image-90[ ]]

Speaker Notes

• 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

Speaker Notes

Quotas

Quotas

Used to control user disk usage.

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

.footnote[.center[options in galaxy.yml]]

Speaker Notes

• 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

class: left

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

Speaker Notes

• 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

Speaker Notes

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

Authentication Systems

Speaker Notes

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

Speaker Notes

• 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

Speaker Notes

• 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

Speaker Notes

• 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

.footnote[.center[options in galaxy.yml]]

Speaker Notes

• 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

Speaker Notes

• 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.

Speaker Notes

• 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

Key Points

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

Thank you!