Okta Identity Provider

Configure Okta as an OpenID Connect (OIDC) identity provider for MinIO AIStor. For general OIDC configuration, see OpenID Connect Identity Management.

Okta is a hosted service, so there is no identity provider to deploy alongside MinIO AIStor. Instead, you register MinIO AIStor as an application in Okta, add a claim that carries the MinIO AIStor policy name, and point MinIO AIStor at the Okta discovery document.

• An Okta organization and administrator access to the Okta Admin Console.
• A MinIO AIStor deployment with outbound network access to your Okta organization endpoints. MinIO AIStor contacts Okta directly for discovery, signing key retrieval, and token validation.
• The mc CLI installed and configured with an alias for your MinIO AIStor deployment.

The steps below register MinIO AIStor as an application and configure the default custom authorization server, which Okta serves at the path /oauth2/default/.

1. In the Okta Admin Console, navigate to Applications > Applications > Create App Integration.
2. Set Sign-in method to OIDC - OpenID Connect and Application type to Web Application, then select Next.
3. Enter an App integration name, for example MinIO AIStor.
4. Leave Grant type set to Authorization Code.
5. Set Sign-in redirect URIs to your Console UI callback address:

   https://minio.example.com/oauth_callback
   

6. Set Sign-out redirect URIs to your Console UI address.
7. Select Save.

On the General tab of the new application, note the Client ID and Client Secret. These values are used for MINIO_IDENTITY_OPENID_CLIENT_ID and MINIO_IDENTITY_OPENID_CLIENT_SECRET.

By default, Okta assigns new application integrations an authentication policy that requires two factors. A user who has not enrolled a second factor cannot sign in to the application.

If your organization does not enroll users in a second factor, create a policy that accepts a password:

1. Navigate to Security > Authentication Policies > Add a policy.
2. Enter a name, for example Password only, then select Save.
3. Select Add Rule and configure the rule:
   • AND User must authenticate with: Password
   • THEN Access is: Allowed after successful authentication
4. Select Save.
5. Open the Applications tab of the policy, select Add app, and add your MinIO AIStor application.

MinIO AIStor reads a JSON Web Token (JWT) claim to determine which policies to attach to an authenticated user. Store the policy name on the Okta user profile so that each user can carry a different policy.

1. Navigate to Directory > Profile Editor and select Okta in the filter list.
2. For Okta User (default), select Profile > Add Attribute.
3. Configure the attribute:
   • Data type: string
   • Display name: MinIO Policy
   • Variable name: minioPolicy
   • Attribute required: No
4. Select Save.

1. Navigate to Security > API and select the default authorization server.
2. Open the Claims tab and select Add Claim.
3. Configure the claim:
   • Name: policy
   • Include in token type: ID Token, then Always, not Userinfo/id_token request, so that Okta issues the claim during the authorization code flow
   • Value type: Expression
   • Value: user.minioPolicy
   • Include in: Any scope
4. Select Create.

policy claim missing from the JWT token, credentials will not be generated

The default authorization server can start with no access policy. Without a policy, Okta authenticates the user but issues no token.

1. Navigate to Security > API > Authorization Servers > default.
2. Open the Access Policies tab.
3. If no policy exists, select Add Policy, enter a name, and set Assign to to The following clients, adding your MinIO AIStor application.
4. Select Create Policy.
5. Select Add Rule and configure the rule:
   • Grant type is: Authorization Code
   • User is: Any user assigned the app
   • Scopes requested: Any scopes
6. Select Create Rule.

1. Navigate to Directory > People and select a user.
2. On the Profile tab, select Edit, set MinIO Policy to the name of a MinIO AIStor policy, for example consoleAdmin, and select Save.
3. Navigate to Applications > Applications, select your MinIO AIStor application, and open the Assignments tab.
4. Select Assign > Assign to People, assign the user, then select Save and Go Back.

The policy name must match an existing MinIO AIStor policy. To use several policies for one user, enter a comma-separated list.

Confirm that the policy claim reaches the ID token before you change the MinIO AIStor configuration:

1. Navigate to Security > API > Authorization Servers > default.
2. Open the Token Preview tab.
3. Set OAuth/OIDC client to your MinIO AIStor application, Grant type to Authorization Code, User to an assigned user, and Scopes to openid profile email.
4. Select Preview Token, then view the decoded ID Token.

The decoded token contains the policy claim with the value from the user profile:

"policy": "consoleAdmin"

If the claim is absent, check that the claim is an ID Token claim set to Always, that the user profile has a value for MinIO Policy, and that the user is assigned to the application.

Open the following URL in a browser to confirm it returns authorization_endpoint and jwks_uri:

https://<okta-domain>/oauth2/default/.well-known/openid-configuration

The Okta integration uses the settings documented in OpenID Settings.

Configure them the way your deployment is managed: use Kubernetes if the AIStor Operator manages your object store, and Linux otherwise. Both routes set the same six variables, so follow one of them, not both.

All six values are the same on either route:

MINIO_IDENTITY_OPENID_REDIRECT_URI_DYNAMIC directs the Console UI to build the redirect URI from the Host header of the originating request. The sign-in redirect URI you registered in Okta must match the address through which users reach the Console UI.

Add the Okta provider using mc:

mc idp openid add ALIAS okta \
  config_url="https://<okta-domain>/oauth2/default/.well-known/openid-configuration" \
  client_id="<client-id>" \
  client_secret="<client-secret>" \
  claim_name="policy" \
  scopes="openid,profile,email" \
  redirect_uri_dynamic="on"

Or set the equivalent environment variables in the service environment:

export MINIO_IDENTITY_OPENID_CONFIG_URL="https://<okta-domain>/oauth2/default/.well-known/openid-configuration"
export MINIO_IDENTITY_OPENID_CLIENT_ID="<client-id>"
export MINIO_IDENTITY_OPENID_CLIENT_SECRET="<client-secret>"
export MINIO_IDENTITY_OPENID_CLAIM_NAME="policy"
export MINIO_IDENTITY_OPENID_SCOPES="openid,profile,email"
export MINIO_IDENTITY_OPENID_REDIRECT_URI_DYNAMIC="on"

Restart MinIO AIStor to apply the configuration:

mc admin service restart ALIAS

On Kubernetes, supply the settings through the objectStore.env field of your Object Store Helm values file, and hold the client secret in a Kubernetes Secret.

1. Write the client secret to a file

   Create the file with owner-only permissions before you put anything in it, so the secret is never world-readable and never enters your shell history:

   install -m 600 /dev/null okta-client-secret
   

   Open okta-client-secret in an editor and paste the Client Secret from the Okta application, with no trailing newline.

2. Create the Secret

   Create it in the namespace where the Object Store Pods run, because valueFrom.secretKeyRef resolves in the pod’s own namespace and cannot reach a Secret anywhere else. This example uses primary-object-store:

   kubectl create secret generic okta-oidc \
     --namespace primary-object-store \
     --from-file=client-secret=./okta-client-secret
   

   Delete okta-client-secret once the Secret exists.

3. Add the settings to your values file

   objectStore:
     env:
     - name: MINIO_IDENTITY_OPENID_CONFIG_URL
       value: "https://<okta-domain>/oauth2/default/.well-known/openid-configuration"
     - name: MINIO_IDENTITY_OPENID_CLIENT_ID
       value: "<client-id>"
     - name: MINIO_IDENTITY_OPENID_CLIENT_SECRET
       valueFrom:
         secretKeyRef:
           name: okta-oidc
           key: client-secret
     - name: MINIO_IDENTITY_OPENID_CLAIM_NAME
       value: "policy"
     - name: MINIO_IDENTITY_OPENID_SCOPES
       value: "openid,profile,email"
     - name: MINIO_IDENTITY_OPENID_REDIRECT_URI_DYNAMIC
       value: "on"
   

4. Apply the configuration

   helm upgrade primary-object-store minio/aistor-objectstore \
     -n primary-object-store \
     -f aistor-objectstore-values.yaml
   

   The Operator restarts the Object Store Pods to apply the new environment variables.

1. Open the Console UI in a browser.
2. Select Login with SSO.
3. Enter your Okta credentials on the redirect page.
4. After successful authentication, you are redirected to the Console UI with access based on your assigned policies.

Applications can programmatically obtain temporary MinIO AIStor credentials using the AssumeRoleWithWebIdentity STS API. The application authenticates with Okta to obtain an ID token, then exchanges it for temporary MinIO AIStor credentials.

Symptom: SSO login does not complete. The AssumeRoleWithWebIdentity response returns policy claim missing from the JWT token, credentials will not be generated.

Cause: The policy claim is not present in the ID token that MinIO AIStor validates.

Solution:

1. Confirm the claim is configured on the default authorization server as an ID Token claim set to Always.
2. Confirm the user profile has a value for MinIO Policy.
3. Confirm MINIO_IDENTITY_OPENID_CONFIG_URL uses the /oauth2/default/ path rather than the Org authorization server.
4. Use Token Preview to inspect the decoded ID token.

Symptom: SSO login does not complete. The AssumeRoleWithWebIdentity response states that none of the given policies are defined, and that credentials will not be generated.

Cause: The claim carries a policy name that does not exist on the MinIO AIStor deployment.

Solution: Create the policy, or change the user profile value to the name of an existing policy:

mc admin policy create ALIAS POLICY_NAME policy.json

Symptom: Okta reports that the user is not allowed to access the application.

Cause: The authentication policy assigned to the application requires a factor the user has not enrolled.

Solution: Assign an authentication policy that the user can satisfy, or enroll the user in the required factor.

Symptom: Okta authenticates the user, but the login does not complete. The Okta system log records no_matching_policy on the app.oauth2.as.authorize event.

Cause: The default authorization server has no access policy that covers the MinIO AIStor application.

Solution: Add an access policy and a rule that allows the authorization code grant.

Symptom: The MinIO AIStor logs report that OpenID initialization failed, or that the Okta hostname does not resolve.

Cause: The MinIO AIStor hosts have no outbound network access to your Okta organization.

Solution: Confirm that the hosts resolve the Okta hostname and can retrieve the discovery document:

curl -s "https://<okta-domain>/oauth2/default/.well-known/openid-configuration"