User, Role, Group, Quota, and Authentication managment
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?
Learn the Galaxy user/group management and assign Quotas.
Understand the Role Based Access Control (RBAC) of Galaxy.
||Prevent anonymous access.|
||Show welcome page next to login page.|
||Allow user registration. When False, admins must create users; often coupled with
||Users can purge (permanently delete) their datasets.|
||List of email addresses of API users who can make calls on behalf of other users.|
||Users to see the full path of datasets via the “View Details” option in the history.|
- 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.
Require verification that a user’s email is real. You must enable SMTP first.
||Require users to click link in email before running jobs.|
||Time (hours) that a user can ‘explore’ Galaxy before activation lockout.|
||Message provided to non-activated users.|
||Defines domains in XXX.YYY format that will be rejected as user emails.|
- 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
||Comma-separated list of admin users’ emails.|
||Admins can delete users.|
||Admins can become other users. Great for debugging / user assistance.|
||Admin super-key allows many API admin actions without having a real admin user.|
- 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
||Users can view other registered usernames.|
||Users can view other registered emails.|
||Newly created datasets are private to the creating user.|
- 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
Roles and Groups
Role Based Access Control (RBAC)
- 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
- 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
.left-column50[ manage permissions
- Users who have associated role on a dataset can manage the roles associated it.
- 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
- When this is set, datasets are private by default. ]
- 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
- 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[ ]]
- 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
Used to control user disk usage.
||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’
- Examples: “10000MB”, “99 gb”, “0.2T”, “unlimited”
- = / + / -
Default for user class:
- None (No)
- Unregistered Users
- Registered Users
or associated with Groups or Users
- 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
- 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
- Quotas are stored in the DB tables
- 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
- 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
- Quotas can be managed through the API
- Some people want to automate this process, but it needs more work.
LDAP / AD
- Galaxy can be configured to use LDAP or Active Directory for authentication
- There is a config file named
- 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
- 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
- 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
- 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
- Galaxy can be configured to use OpenID Connect for authentication
- There are two configuration files:
- Supports a variety of providers:
- LS Login (Elixir AAI)
- 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
||Days before requiring a user to change password. (NIST recommends not requiring password changes.)|
||Minutes before invaliding a user’s session, requiring re-login.|
- 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
- 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
- Galaxy will trust this header
- 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
- 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
- This will send an additional secret header to Galaxy that will be validated
- Otherwise local users can
curlyour Galaxy server, and impersonate any user.
- An important aspect for security is that if you have local users on the Galaxy head node
- Then you should set the
remote_user_secretoption, to prevent them impersonating other users
- Galaxy has a powerful user and group managment system that can be utilized for Quota management.