FR: API access with Kerberos credentials
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:
- 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
. - 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. - 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.