Arvados

There is a feature to "pre-register" a user by creating a permission link from the user email to the user uuid.

It seems that with deterministic user uuids this feature could be superceded by giving the admin a way to create an account with the uuid that would be generated for a given email address?

After spending a while mulling over implementation strategy, I think we want to create a new API endpoint called "fedlogin" (only enabled on the master cluster). This new endpoint will allow the subordinate clusters to forward along the 'info' hash we get from SSO (contains user name, email) and return the user record to use.

The rationale is that if a user with multiple email aliases logs in for the first time on a subordinate cluster, the action of probing for potential user record, creating records on the master cluster, and setting up redirects is complicated, risky, and slow if spread across multiple API calls, any of which could fail and result in inconsistent state or behavior. A single call is transactional and ensures consistent behavior.

Revised design for delegating user accounts to master cluster.

1. Instead of logging in to a local SSO provider, designate a home cluster (cluster A) where login is always sent (this is 'AssignUUIDPrefix' but it should probably be called something else like 'LoginCluster' or 'MasterCluster')
2. After logging in, user is sent to original cluster (cluster B) with a token issued by the home cluster (cluster A)
3. If cluster A's RemoteHosts for cluster B has a 'trusted' flag, send unsalted token (this is 'AuthenticateLocalUsers' but it should probably be called something else like 'TrustWithUnsaltedToken')
4. Users from master cluster A have extra trust on cluster B (respects admin flag)
5. Tokens get a 'refresh_at' date in addition to existing expires_at. Attempt to contact master cluster after 'refresh_at', succeed or fail it sets a new 'refresh_at', does not prevent login until past 'expires_at'

Multi-email login should be done in a separate branch.

1. Start by looking up identity_url
2. If identity_url is not found, look up records for each email address in the 'info' field
3. If there's more than one user with the same email address and it is ambiguous which record to use, login fails.
4. If no user record is found, create user records for each email address and link the alternate ones to the primary one
5. Sync identity_url, email address, name on the user record that was selected.
6. Make sure 'email' field is not user editable (when we actually need to send mail, check user preferences?)

Migration.

1. Need to be able to create user accounts through the API with just an email address
2. Merge account feature must be able to have local user account take over a remote account

15529-federated-user-accounts @ fb5b1feb7acdfafed1bcbe932ff90e95e129c2a3

https://ci.curoverse.com/view/Developer/job/developer-run-tests/1487/

The existing token validation code uses ApiClientAuthorization.remote_host(id) to get the configured Host, fall back to {id}.arvadosapi.com. Seems like we should use the same strategy/function when finding a remote cluster's endpoint for LoginCluster purposes. (That remote_host() function also requires Proxy: true, which seems like a sensible requirement for using a remote as a LoginCluster -- e.g., "get current user record after logging in" won't work without it.)

I probably shouldn't care so much about comments, but Invarient → Invariant

Rest LGTM, thanks!

Tom Clegg wrote:

The existing token validation code uses ApiClientAuthorization.remote_host(id) to get the configured Host, fall back to {id}.arvadosapi.com. Seems like we should use the same strategy/function when finding a remote cluster's endpoint for LoginCluster purposes. (That remote_host() function also requires Proxy: true, which seems like a sensible requirement for using a remote as a LoginCluster -- e.g., "get current user record after logging in" won't work without it.)

Fixed.

I probably shouldn't care so much about comments, but Invarient → Invariant

Fixed.

Rest LGTM, thanks!

15529-federated-user-accounts @ 068e72307f9ce91538e45cb461b99cf92d2f5666

https://ci.curoverse.com/view/Developer/job/developer-run-tests/1502/

LGTM, thanks