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:

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.
  1. User: Make request with no credentials (like access token or cookie).

  2. Istio Gateway: Intercept this request and send it to the AuthService.

  3. 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.

  4. AuthService: Respond to Istio Gateway with an HTTP redirect to the OIDC provider login page, with the state, client ID, and callback URL.

  5. Istio Gateway: Forward this response to the user.

  6. User: Request the OIDC provider login page, and log in the Identity Provider. Consent to log in to Kubeflow from the Identity Provider.

  7. Identity Provider: Respond to the user with an HTTP redirect to the AuthService callback URL. Include authorization code and state as query parameters.

  8. User: Request the AuthService callback URL, adding the authorization code and state as query parameters.

  9. AuthService: Verify that the state matches the one AuthService created in step 3. Only then send the authorization code to the Identity Provider.

  10. Identity Provider: Respond to AuthService with the access, refresh (optional), and ID token for the user.

  11. AuthService: Send a request to the Token Introspection Endpoint of the Identity Provider to get more information about the user.

  12. Identity Provider: Respond with the full list of the claims for the user.

  13. AuthService: Set a new session for this user.

  14. 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.

  15. User: Request the reception endpoint with the ?next query parameter and the cookie.

  16. Istio Gateway: Forward the request to the AuthService.

  17. AuthService: Verify that the request can proceed.

  18. Istio Gateway: Forward the response to Kubeflow Reception.

  19. 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 be kubeflow. The <USERID> varies. For example, let’s assume a user with email user@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 be kubeflow-user.
  20. 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.

  21. Kubernetes: Create a resource of type Profile and respond back to Kubeflow Reception.

  22. Profile Controller: Watch Kubernetes API Server for Profile resources.

  23. 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:

  24. Kubernetes: Create the service accounts and the RoleBindings and respond back to Kubeflow Reception.

  25. Reception: Wait for the user to be bound to the new profile.

  26. 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.

  27. Istio Gateway: Forward the response to the user.

  28. User: Request the original URL with the cookie.

  29. Istio Gateway: Forward the request to the AuthService.

  30. AuthService: Check if the Kubernetes authentication method can authenticate this request.

    Note

    When authenticating a client with their cookie this check will fail.

  31. 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.

  32. AuthService: Authenticate the user based on the session from the cookie.

  33. AuthService: Respond to Istio Gateway that the user was successfully authenticated (HTTP 200 status) and set the UserID header for the user.

  34. Istio Gateway: Forward the request to Kubeflow with the UserID header.

  35. Kubeflow: Perform the action that the user requested and respond to Istio Gateway.

  36. 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).