End-to-End User Authentication¶
This guide describes end-to-end how AuthService performs authentication for a user.
Here’s what you’ll need so that you can authenticate with OIDC:
- An Arrikto EKF deployment integrated with an external (Identity Provider).
- An existing user account for this Identity Provider.
Step-by-Step Analysis¶
Here is a step-by-step description of how
- unauthenticated users follow the Authorization Code Flow (OIDC flow) to acquire their authentication credentials,
- Kubeflow Reception creates accounts for these users,
- AuthService authenticates users based on their cookies.
User: Make request with no credentials (like access token or cookie).
Istio Gateway: Intercept this request and send it to the AuthService.
AuthService: Try every one of the authenticators to authenticate the user.
Note
All of the authenticators will fail in this case. AuthService initiates the Authorization Code Flow (OIDC Flow). It creates a state for this user request, which contains the original URL of the initial request.
AuthService: Respond to Istio Gateway with an HTTP redirect to the OIDC provider login page, with the state, client ID, and callback URL.
Istio Gateway: Forward this response to the user.
User: Request the OIDC provider login page, and log in the Identity Provider. Consent to log in to Kubeflow from the Identity Provider.
Identity Provider: Respond to the user with an HTTP redirect to the AuthService callback URL. Include authorization code and state as query parameters.
User: Request the AuthService callback URL, adding the authorization code and state as query parameters.
AuthService: Verify that the state matches the one AuthService created in step 3. Only then send the authorization code to the Identity Provider.
Identity Provider: Respond to AuthService with the access, refresh (optional), and ID token for the user.
AuthService: Send a request to the
Token Introspection Endpoint
of the Identity Provider to get more information about the user.Identity Provider: Respond with the full list of the claims for the user.
AuthService: Set a new session for this user.
AuthService: Redirect the user to the reception endpoint with a cookie and the proper
?next
query parameter.Note
AuthService retrieves the original URL from the state it created in step 3 for the user. AuthService sets the
?next
query parameter to include a relative path to the original URL. Then AuthService redirects the user to the/reception?next=<ORIGINAL-URL>
, for example,/reception?next=%2Fnotebook%2Fkubeflow-user%2Fmytest%2Flab
.User: Request the reception endpoint with the
?next
query parameter and the cookie.Istio Gateway: Forward the request to the AuthService.
AuthService: Verify that the request can proceed.
Istio Gateway: Forward the response to Kubeflow Reception.
Reception: Retrieve the UserID from the header and generate the profile name for this user.
Note
The profile name will be
<PROFILE-PREFIX>-<USERID>
. All.
and@
characters will be replaced with-
. In our case, the<PROFILE-PREFIX>
will bekubeflow
. The<USERID>
varies. For example, let’s assume a user with emailuser@example.com
:- if the user logs in with OIDC to Kubeflow then the profile name will
be
kubeflow-user-example-com
. - if the user is using an external Identity Provider (such as PingID)
as an OIDC provider for Kubeflow and has configured
USERID_TRANSORMERS
(for example see step 13 of PingID) then the profile name will bekubeflow-user
.
- if the user logs in with OIDC to Kubeflow then the profile name will
be
Reception: If there is not a profile for this profile name, then request from the Kubernetes API Server to create a resource of type
Profile
for this user.Kubernetes: Create a resource of type
Profile
and respond back to Kubeflow Reception.Profile Controller: Watch Kubernetes API Server for
Profile
resources.Profile Controller: Create a new namespace for this new
Profile
resource. Create two service accounts for this user. Create the respective RoleBindings to enforce the proper permissions for this user.Note
Regarding the service accounts and the RoleBindings, Profile Controller sets the editor and view permissions of this user respectively.
See also
For more information see the following guides:
Kubernetes: Create the service accounts and the RoleBindings and respond back to Kubeflow Reception.
Reception: Wait for the user to be bound to the new profile.
Reception: Retrieve the original URL that the user attempted to request (before logging in) from the
?next
query parameter of the URL. Redirect the user to this URL.Note
If AuthService redirected the user to
/reception?next=%2Fnotebook%2Fkubeflow-user%2Fmytest%2Flab
in step 3, then Kubeflow Reception will grab the?next
query parameter from the URL and will respond with a relative redirect to/notebook/kubeflow-user/mytest/lab
.Istio Gateway: Forward the response to the user.
User: Request the original URL with the cookie.
Istio Gateway: Forward the request to the AuthService.
AuthService: Check if the Kubernetes authentication method can authenticate this request.
Note
When authenticating a client with their cookie this check will fail.
AuthService: Check if one of the access token authentication methods can authenticate this request.
Note
When authenticating a client with their cookie this check will fail.
AuthService: Authenticate the user based on the session from the cookie.
AuthService: Respond to Istio Gateway that the user was successfully authenticated (
HTTP 200
status) and set the UserID header for the user.Istio Gateway: Forward the request to Kubeflow with the UserID header.
Kubeflow: Perform the action that the user requested and respond to Istio Gateway.
Istio Gateway: Forward the response to the user.
Summary¶
In this guide you gained insight on how AuthService authenticates a user end-to-end.
What’s Next¶
The next guide presents how Arrikto EKF performs authorization based on Kubernetes Role-Based Access Control (RBAC).