FR: API access with Kerberos credentials

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Description

Currently there is a way to access API from an SPNEGO-capable client, but it is rather a hack and as such, I am afraid, might disappear with any new upgrade. I do it like this:

1. Perform a normal SPNEGO authentication to https://gitlab/users/auth/kerberos_spnego/negotiate. There is a 401 response for the initial leg, and then a 302 Redirect response. This response also sets a session cookie _gitlab_session.
2. The second crucial step is to follow the redirect once, passing back the session cookie. (The redirect leads to https://gitlab/users/auth/kerberos_spnego/callback). Without this, attempting API access with the new _gitlab_session cookie still returns {"message":"401 Unauthorized"}, as if the session is not yet authenticated. This second request also results in a 302 (redirecting to the main page of GitLab), but I ignore it.
3. Now the API can be accessed using the _gitlab_session cookie, with my own Kerberos identity!

Proposal

I number the options 1 the best down to 3 the worst, but list them in the order of exposition. Sorry if that looks weird.

Option 1

To me it seems the best one, unless I misappreciate the overall impact: When accessing the API, if the token is NOT provided (No PRIVATE-TOKEN: or Authorization header, no ?private_token= in the URL, and no valid _gitlab_session), then initiate SPNEGO authentication by adding WWW-Authenticate: Negotiate header to the returned 401 response (and support the second leg, of course). This probably won't break any existing use of the API.

Option 3

Simply document the existing solution above: Go to /users/auth/kerberos_spnego/negotiate, get the cookie and the redirect, follow the redirect to bake the cookie, then use the cookie for API access while it works; when it stops, rinse and repeat.

This will at the very least keep me sleeping better at night, knowing that the endpoint and the trick is not going away without a warning.

Option 2

Create and document separate Kerberos authentication endpoint for API: Almost same as Option 3, only would (a) document a different endpoint, e. g. /api/kerberos_spnego/negotiate and (b) the endpoint would not require the redirect, and instead just return a 200/204 or a 401 response, set a valid _gitlab_session cookie on success, and may contain a JSON body in line with the rest of the API. This is arguably cleaner and less error-prone than the esoteric Option 3.