Feature #10287
closed
[SSO] [API] Assign Arvados username from site-configured LDAP field when available
Added by Peter Amstutz about 8 years ago.
Updated about 8 years ago.
Estimated time:
(Total: 0.00 h)
Description
Currently Arvados generates a username from a user's email address. However, some installations using external authentication (e.g. LDAP) may have usernames assigned which are separate from the email address used to log in, and don't match.
Arvados should be able to discover and use the username from external authentication so that the username used for VM login, git, and other accounting is consistent with the rest of the organization.
Implementation¶
New API server configuration parameter "sso_username_field":
- "email" (default) means use local part of email address (i.e., current behavior)
- "uid", "cn", or anything else means use the indicated field from the SSO info hash
Ensure SSO provider propagates the "uid" and "cn" fields (and any other available fields) from LDAP to Arvados API.
- Description updated (diff)
- Subject changed from [SSO] Assign Arvados 'username' from LDAP 'username' when available to [SSO] [API] Assign Arvados username from site-configured LDAP field when available
- Description updated (diff)
- Category set to SSO
- Status changed from New to In Progress
- Assigned To set to Peter Amstutz
- Target version set to 2016-10-26 sprint
Posted branches:
10287-sso-username (sso-provider repo)
10287-ldap-username (arvados)
sso_provider in app/controllers/users/omniauth_callbacks_controller.rb
+
+ username = if ldap_conf['username']
+ request.env['omniauth.auth']['extra']['raw_info'][ldap_conf['username'].to_sym][0]
+ end
+
What if we don't have ldap_conf['username'] ? shall we have an "else" there that assigns something safe ? If this get's propagated to api servers, I would not like to override existing usernames.
Nico Cesar wrote:
What if we don't have ldap_conf['username'] ? shall we have an "else" there that assigns something safe ? If this get's propagated to api servers, I would not like to override existing usernames.
API server will ignore this (i.e., fall back on previous behavior and use the local part of the email address) if username ends up nil here.
- Status changed from In Progress to Resolved
tested username gets populate correctly
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by