Authentication with External Identity Providers using Opaque Tokens

This guide describes how AuthService performs authentication for client requests that use an opaque access token from an external Identity Provider (such as PingID).

Here’s what you’ll need so that you can authenticate with an external IdP using an opaque token:

• Integration of your Arrikto EKF installation with an external Identity Provider.
• An opaque access token from your external Identity Provider.
• AuthService must be configured to perform remote access token validation.

Note

You can use this method of authentication even if you use a JWT as an access token. In this case, the AuthService will simply treat it as an opaque token, meaning that it will not check its claims and all the following steps will apply.

Under construction

This feature is a work in progress.

Step-by-Step Analysis

Here is a step-by-step explanation of how AuthService authenticates clients based on their opaque access token.

1. Client: Perform HTTP request to Kubeflow with an access token in the Authorization header.

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

3. AuthService: Check whether the HTTP request has a cookie.

   Note

   When authenticating with an external IdP, the client does not have a cookie, so this check will fail. The client has an Authorization header granted from the external Identity Provider.

4. AuthService: Check whether the HTTP request has an Authorization header. Retrieve the access token from the Authorization header.

   Note

   If the client makes a request with no credentials, this check will also fail. AuthService will then perform the authentication via the OIDC Authorization Code Flow. Find out more about this authentication method here:

   • Login with OIDC

Important

If the AuthService caching mechanism is enabled and the retrieved Bearer token exists in the cache, then AuthService will skip both Step 5 and Step 6 (see the respective dotted arrows in the above diagram). You can find out more on how to enable the AuthService caching mechanism in the Enable AuthService Caching Mechanism guide.

5. AuthService: Send the access token to the Token Introspection Endpoint of the external Identity Provider.

6. AuthService: Retrieve the User ID and the groups of the user from the successful response of the external Identity Provider, using the USERID_CLAIM and GROUPS_CLAIM configuration options of AuthService.

   Note

   If the access token is not valid, the external Identity Provider will respond with an error response. AuthService will then continue with the Kubernetes authenticator. Find out more on the Kubernetes authenticator here:

   • Authentication with Kubernetes Service Accounts

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

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

9. Kubeflow: Perform the action that the client requested and respond back to Istio Gateway.

   See also

   See more on how Kubeflow performs authorization by using Kubernetes RBAC:

   • Authorization with Kubernetes RBAC

10. Istio Gateway: Forward the response to the client.

See also

• Find out how you can perform Authentication with External Identity Providers Using JWT, in order to let AuthService validate requests without asking the external Identity Provider.
• Find out about the Identity Providers that you can integrate your Arrikto EKF deployment with.
• Find out more regarding the Bearer Token usage by checking The OAUTH 2.0 Authorization Framework: Bearer Token Usage proposed standard.

Summary

In this guide you gained insight on how AuthService performs authentication for client requests that use an opaque access token from an external Identity Provider.

What’s Next

The next guide presents how the AuthService performs authentication with OpenID Connect (OIDC) when a user makes a request with no credentials.

• Login with OIDC

PreviousNext