GitLab Geo: OAuth Authentication

Rationale

Current implementation requires Geo (#76) to share Redis connection between primary and secondary nodes, in order to make authentication possible.

We can't authenticate directly to the secondary nodes because Devise must save state data to the Database for modules like:

• Recoverable
• Registerable (we don't need it on a secondary node)
• Rememberable
• Trackable
• Lockable

Disabling some of them may have security consequences. In the future if we decide being able to authenticate on a secondary is a requirement, we will have to patch Devise and store state data in another datastore (like Redis), or implement a more sophisticated master <-> master replication topology.

OAuth Authentication

OAuth authentication is the most obvious way to implement a remote login protocol and share authentication status in the context of a user session.

GitLab already supports acting as an OAuth Identity Provider (we use DoorKeeper for that).

The idea is to create automatically an OAuth Application (see /admin/applications), and link it to a secondary Geo Node.

Authentication Workflow

When user wants to login, it will redirect to OAuth Identity Provider (primary Geo node), and will add to the state param, the return_to url, in the same way GitLab CI did.

User will connect to the primary node using any type of authentication defined there.

On first access he/she will be redirected to the OAuth authorization screen (where he/she must "Allow" the application).

After the first access, it will be transparent and automatically redirected to the secondary node.

Checklist

• When a secondary Geo node is created an OAuth Application is created associated to it
• When a secondary Geo node is removed the associated OAuth application is also removed
• When a user tries to login it must be redirected to the primary node using the OAuth workflow
• The user must be redirected to the "first accessed url before authentication" (as expected)
• User should be able to logout from a secondary node
• It displays authentication errors when OAuth application is not present
• It handles authentication errors when OAuth flow fails
• Solution for what to do when/if OAuth application is removed

Undecided behavior:

What happens when user removes a Geo node related OAuth application? What happens with users who upgrade from 8.5 and doesn't have a Geo Node with OAuth authentication present?

Alternatives:

• We should prevent it from happening
• We should display an "Repair authentication" on the Geo Node list, when OAuth is not present.
• We should have a button on Geo Node list to "enable" or "disable" OAuth authentication (a disabled authentication means that you can't access secondary node by Web).

We can have one Application for each secondary node, or a single one on associated with the primary and shared between all of them.

There are tradeoffs on both. If we go to a single one, we can't easily "disable" login for a specific secondary node. If we create one for each secondary node, users will have to "allow" for the first time on each secondary node.

Going more granular can give valuable forensic information as "user X" has access to "secondary Node Y".

cc @DouweM @dzaporozhets

mentioned in merge request !237 (merged)

Marked the task The user must be redirected to the "first accessed url before authentication" (as expected) as completed

Marked the task User should be able to logout from a secondary node as completed

Marked the task When a user tries to login it must be redirected to the primary node using the OAuth workflow as completed

Added ~164929 label

Marked the task It handles authentication errors when OAuth flow fails as completed

Marked the task It displays authentication errors when OAuth application is not present as completed

mentioned in merge request !236 (merged)

@brodock

We should display an "Repair authentication" on the Geo Node list, when OAuth is not present.

We should have a button on Geo Node list to "enable" or "disable" OAuth authentication (a disabled authentication means that you can't access secondary node by Web).

I am ok with any of this.

We can have one Application for each secondary node, or a single one on associated with the primary and shared between all of them.

I propose we choose based on simplicity of code/implementation.

If we create one for each secondary node, users will have to "allow" for the first time on each secondary node.

I think its ok since you will usually work with only one secondary node.

cc @DouweM

"Repair authentication" button on Geo Node list and one OAuth application per secondary GeoNode are the simplest solutions.

Marked the task When a secondary Geo node is removed the associated OAuth application is also removed as completed

Marked the task When a secondary Geo node is created an OAuth Application is created associated to it as completed

"Repair authentication" button will only be visible when the OAuth application is accidentally removed (or when not present because an existing user from 8.5 migrated to 8.6)

Marked the task Solution for what to do when/if OAuth application is removed as completed

mentioned in commit 197b1954

Status changed to closed

mentioned in issue #76

Mentioned in issue #76

Mentioned in commit maxraab/gitlab-ce@197b1954