Select one of the following login mechanisms for your cluster.
With this configuration, users will sign in with their Google accounts.
Use the Google Developers Console to create a set of client credentials.
Login: Google: Enable: true ClientID: "0000000000000-zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.apps.googleusercontent.com" ClientSecret: "zzzzzzzzzzzzzzzzzzzzzzzz"
With this configuration, users will sign in with a third-party OpenID Connect provider such as GitHub, Auth0, Okta, or PingFederate.
Similar to the Google login section above, you will need to register your Arvados cluster with the provider as an application (relying party). When asked for a redirect URL or callback URL, use
https://ClusterID.example.com/login (the external URL of your controller service, plus
The provider will supply an issuer URL, client ID, and client secret. Add these to your Arvados configuration.
Login: OpenIDConnect: Enable: true Issuer: https://accounts.example.com/ ClientID: "0123456789abcdef" ClientSecret: "zzzzzzzzzzzzzzzzzzzzzzzz"
Arvados can also be configured to accept provider-issued access tokens as Arvados API tokens by setting
true. This can be useful for integrating third party applications.
Login: OpenIDConnect: AcceptAccessToken: true AcceptAccessTokenScope: "arvados"
Login.OpenIDConnect.AcceptAccessTokenScopeis not empty, Arvados will check that the token contains the configured scope, and reject tokens that do not have the configured scope. This can be used to control which users or applications are permitted to access your Arvados instance.
Check the OpenIDConnect section in the default config file for more details and configuration options.
With this configuration, authentication uses an external LDAP service like OpenLDAP or Active Directory.
Enable LDAP authentication and provide your LDAP server’s host, port, and credentials (if needed to search the directory) in
Login: LDAP: Enable: true URL: ldap://ldap.example.com:389 SearchBindUser: cn=lookupuser,dc=example,dc=com SearchBindPassword: xxxxxxxx SearchBase: ou=Users,dc=example,dc=com
The email address reported by LDAP will be used as primary key for Arvados accounts. This means users must not be able to edit their own email addresses in the directory.
Additional configuration settings are available:
StartTLSis enabled by default.
AppendDomainmodify the username entered by the user before searching for it in the directory.
uid) is the LDAP attribute used when searching for usernames.
SearchFiltersaccepts LDAP filter expressions to control which users can log in.
Check the LDAP section in the default config file for more details and configuration options.
With this configuration, authentication is done according to the Linux PAM (“Pluggable Authentication Modules”) configuration on your controller host.
Enable PAM authentication in
Login: PAM: Enable: true
Check the default config file for more PAM configuration options.
The default PAM configuration on most Linux systems uses the local user/password database in
/etc/shadow for all logins. In this case, in order to log in to Arvados, users must have a UNIX account and password on the controller host itself. This can be convenient for a single-user or test cluster. Configuring a user account with a shell of
/bin/false will enable the user to log into Arvados but not log into shell login on the controller host.
PAM can also be configured to use other authentication systems such such as NIS or Kerberos. In a production environment, PAM configuration should use the service name (“arvados” by default) and set a separate policy for Arvados login. In this case, Arvados users should not have shell accounts on the controller node.
For information about configuring PAM, refer to the PAM System Administrator’s Guide.
The content of this documentation is licensed under the
Commons Attribution-Share Alike 3.0 United States licence.
Code samples in this documentation are licensed under the Apache License, Version 2.0.