Access Management 2.0 Identity Provider UI Field Concepts (OIDC)

Introduction

When configuring an OIDC Identity Provider (IdP) in Access Management 2.0 (where Access Management 2.0 acts as the Relying Party or Service Provider and a third-party system—like Okta, Azure Entra ID, Google—is the Identity Provider), the Access Management 2.0 Admin Console UI exposes a set of UI fields. Here is a detailed explanation of each, with real-world examples to make it concrete:

Redirect URI

Definition:
The URI on the Access Management 2.0 side that the external IdP (e.g., Google, Okta) will redirect back to after a user successfully authenticates.

Access Management 2.0’s Role:
It will send this redirect URI as the redirect_uri parameter in the OIDC Auth Request. The external IdP must be configured to allow this redirect URI.

Example: https://kcstk03-auth.cp.manh.cloud/auth/realms/maactive/broker/oidckc/endpoint

Real-life analogy:
It’s like telling Google, “After login, send the user back to this exact Access Management 2.0 URL.”

Alias

Definition:
An internal identifier used by Access Management 2.0 to refer to this identity provider. It is part of the redirect URI above and must be unique.

Used in URL path like: /realms/{realm}/broker/{alias}/…

Example:
google or okta-tenant1

Real-life analogy:
Think of it as a unique nickname or code name you use internally to refer to a contact in your phone.

Display Name

Definition:
What shows up on the Access Management 2.0 login screen for end users to select the IdP.

Example:
“Login with Google” or “Enterprise SSO”

Real-life analogy:
This is the label on a doorbell that says “Press here to ring Google.”

Display Order

Definition:
An integer that controls the order of appearance of Identity Providers on the login screen. Lower numbers appear first.

Example:

• Google: 1
• Azure AD: 2

Real-life analogy:
It’s like choosing the shelf position for items in a menu — more important ones go at the top.

Use Discovery Endpoint

Definition:
When enabled, Access Management 2.0 will auto-fetch the OIDC configuration of the IdP using its /.well-known/openid-configuration endpoint.

When disabled, you must enter the endpoints (authorization, token, logout, user info) manually.

Real-life example:
With Google, this would fetch from:
https://accounts.google.com/.well-known/openid-configuration

Real-life analogy:
This is like using the metadata file of a system to auto-fill all the fields instead of typing them manually.

Well-Known Endpoint/Discovery Endpoint URL

Definition:
URL where Access Management 2.0 can fetch all necessary OIDC metadata from the IdP: token endpoint, auth endpoint, supported scopes, signing keys, etc.

Example:
https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration

Real-life analogy:
It’s like the public LinkedIn page of an organization that tells you how to contact them and what protocols they follow.

Available Options for Client Authentication

When Access Management 2.0 (as the RP/client) talks to the IdP’s token endpoint, it must authenticate itself. The options available are:

a. Client ID & Secret (client_secret_basic or client_secret_post)

Most common for confidential clients.

Example:

• Client ID: my-client
• Client Secret: *******
• Sent either in HTTP headers (client_secret_basic) or in the request body (client_secret_post).

Caution: Never use "*******" as an actual client secret.
It is often used in examples to mask sensitive data but should never be configured as a real value in any environment.
Doing so would create a serious security vulnerability.

b. Client Assertion (Private Key JWT/Client JWT)

Access Management 2.0 uses a private key to sign a JWT and authenticate with the IdP.

This method is used in high-security environments or when mutual trust is established through certificates.

Real-life analogy:

• Client ID/secret is like a username/password login.
• Client assertion is like showing your digital certificate to prove your identity.

Client ID

Definition:
This is the identifier Access Management 2.0 uses to represent itself as a client to the external IdP.

Example:
If your Okta app’s client ID is 0oa1abcxyz, then enter that in Access Management 2.0.

Client Secret

Definition:
The shared secret between Access Management 2.0 and the IdP used to authenticate Access Management 2.0 when requesting tokens.

Example:
Generated in the external IdP UI when registering the Access Management 2.0 client.

Client Assertion Signature Algorithm

Definition:
When using client assertions (JWT), this setting tells Access Management 2.0 which algorithm to use to sign its authentication JWT.

Examples:

• RS256 (most common)
• ES256

Real-life analogy:
It’s like choosing whether to sign your official document with a fountain pen or a ballpoint pen — different formats, same idea.

Advanced Settings

a. Store Tokens

Definition:
This toggle controls whether Access Management 2.0 should store the access token, refresh token, and ID token received from the external Identity Provider (IdP) after successful authentication.

When enabled, these tokens are stored in the Access Management 2.0 user session and can be accessed by applications via Access Management 2.0 token introspection or user info endpoints.

Real-life analogy:
Think of this like keeping a copy of your parking receipt after entering a garage.
If you keep it (store tokens), you can prove you’ve paid and re-enter if needed. If you don’t, you’ll need to go back to the entrance every time for a new one.

b. Stored Tokens Readable

Definition:
This toggle controls whether the stored tokens (access token, refresh token, ID token) can be accessed by client applications using Access Management 2.0’s token retrieval APIs (like the userinfo or token endpoint).

• When enabled: The stored tokens are exposed to applications that request them.
• When disabled: The tokens are stored but not accessible to applications—useful for security or privacy-conscious setups.

Real-life analogy:
Imagine you deposit a sealed envelope at a bank that contains important documents (tokens).

• If the toggle is ON: You give the bank permission to open the envelope and read its contents whenever needed—for example, if a trusted partner requests verification.
• If the toggle is OFF: The bank stores the envelope securely but will not open it or allow anyone else to open it—even if they know what’s inside might be useful.

c. Trust Email

Definition:
When enabled, Access Management 2.0 assumes that the email address provided by the Identity Provider (IdP) is verified and trustworthy. It will not send a verification email to the user.

When disabled, Access Management 2.0 requires the user to verify the email, even if the IdP claim is valid.

Real-life analogy:
Imagine you are at the front desk of a hotel:

• If the toggle is ON: The receptionist sees your company ID badge and immediately gives you a room key, trusting that your employer already verified your identity.
• If the toggle is OFF: The receptionist still asks for your passport and takes a photo, even with the company ID—they want to verify for themselves.

d. Account linking only

Definition:
When enabled, users cannot use this Identity Provider (IdP) to log in directly. Instead, the IdP can only be used to link additional accounts to an existing Access Management 2.0 account (e.g., from the Account Console).

This is useful when you want to let users add external IdPs to their profile for extra login methods but not use them to create or authenticate accounts on their own.

Real-life analogy:
Think of it like adding a backup credit card to your online shopping account:

• If the toggle is ON: You can’t use this card to create a new account or make the first purchase, but you can link it to an existing account for future purchases.
• If the toggle is OFF: The card can be used freely, including to sign up or log in directly.

e. Hide on Login Page

Definition:
When enabled, this Identity Provider (IdP) will not appear as a login option on the Access Management 2.0 login page. However, it can still be used for login if triggered via identity provider hints, authentication flows, or account linking.

This is useful when the IdP should be available only in specific scenarios (e.g., internal flows or dedicated clients) but not visible to all users by default.

Real-life analogy:
Think of it like a “hidden entrance” to a building:

• If the toggle is ON: The door exists, but it’s not visible to the public. Only people who know the path or have a key (like internal staff) can access it.
• If the toggle is OFF: The door is visible and accessible to everyone walking by.

f. First Login Flow

Definition:
The First Login Flow is the authentication flow executed when a user logs in through an Identity Provider (IdP) for the very first time.

This flow defines what steps Access Management 2.0 should perform the first time it sees a user authenticated via an external IdP — such as linking accounts, updating user profiles, setting required actions, or verifying email.

Real-life analogy:
It’s like a new employee onboarding process:

• When someone joins a company (first login), they go through orientation: fill out forms, verify details, and maybe link their personal ID.
• But on every login after that, they just badge in — no need for all the setup.

In Access Management 2.0 terms:

• First login flow = orientation
• Subsequent logins = just checking in

g. Post Login Flow

Definition:
The Post Login Flow is the authentication flow that Access Management 2.0 executes after a user has successfully authenticated, typically through an Identity Provider (IdP).

It allows you to run additional checks or actions after login, such as:

• Triggering user attribute updates
• Enforcing terms and conditions
• Applying custom authenticators
• Adding consent screens

This flow is optional and only runs if explicitly configured for an IdP or client.

Real-life analogy:
It’s like a security checkpoint you pass after entering a building:

• You’ve already shown your ID and entered (authenticated).
• Now, before proceeding, you might be asked to agree to company policies, sign a visitor log, or verify your access level.

So, in Access Management 2.0:

• Post Login Flow = final gate of custom rules after you’ve successfully logged in

h. Sync Mode

Definition:
Sync Mode defines how user data from an external Identity Provider (IdP) (like Azure AD, Okta, etc.) is synchronized with Access Management 2.0’s internal user storage.

There are two main sync modes:

1. Import (Default)

• Behavior: User data is imported into Access Management 2.0’s local database upon first login. Future logins use the locally stored data unless the IdP is queried again.
• Pros: Faster login times, reduced external calls, and local user persistence.
• Cons: Data may become outdated if user attributes change in the IdP.

2. Force (also known as “Legacy” or “Legacy Sync”)

• Behavior: Every login pulls fresh user data directly from the external IdP.
• Pros: Always up-to-date user information.
• Cons: Slower logins, increased dependency on IdP availability.

Real-life analogy:

• Import Mode: Like taking a snapshot of someone’s ID at reception. You use that local copy for future visits.
• Force Mode: Like calling the person’s office every time they arrive to confirm their title and access level.

Mappers

Definition:
Mappers in Access Management 2.0 define how user attributes or claims from an external Identity Provider (IdP) are translated and mapped into Access Management 2.0’s internal user model or OIDC/SAML tokens.

Key Types of Mappers

• Identity Provider (IdP) Mappers
  Used when federating users from external IdPs into Access Management 2.0.

• Protocol Mappers
  Used when issuing tokens to client applications to control the structure and content of tokens.

Common Use Cases

• Map emailAddress from an IdP to the Access Management 2.0 user’s email field.
• Add custom roles or groups to a user’s token.
• Map LDAP attributes to Access Management 2.0 fields (in LDAP federation).
• Rename or transform a claim before it’s included in a token.

Examples

Real-life analogy:
Think of mappers like a translator at a conference:

• The speaker (external IdP) says something in one language, like "username".
• The translator (mapper) converts that into a form the audience (Access Management 2.0 or the client application) understands, like "preferred_username".

Mappers ensure seamless communication between different identity systems and applications.

Permissions

Definition:
Permissions in Access Management 2.0 control 2.0 who can manage or interact with an Identity Provider (IdP) once it is created. These are part of Access Management 2.0’s fine-grained authorization system and are governed by policies, roles, and scopes.

When permissions are enabled for an IdP, Access Management 2.0 applies Authorization Services to enforce access rules.

Example Use Cases

• Restrict who can edit or delete an IdP.
• Limit which users can trigger sync or link accounts with the IdP.
• Hide sensitive configurations (like client secrets) from users without proper roles.

Real-life analogy:
Think of an Identity Provider as a shared printer in an office:

• Some users can only see it in the list.
• Some can print (use it for login).
• Only a few can reconfigure or remove it.

Permissions ensure that only authorized personnel can make critical changes or view sensitive information related to the IdP.

Enabled

Definition:
The “Enabled” toggle determines whether the configured Identity Provider (IdP) is active and available for use in the login flow.

Functionality

• Enabled:
  Users can authenticate through this IdP. It appears on the login page and is processed normally during authentication flows.

• Disabled:
  The IdP is effectively turned off. It won’t show up on the login page and cannot be used for login unless specifically invoked through backend mechanisms (e.g., custom flows or direct linking).

Real-life analogy:
This is like a light switch for the login option:

• When the switch is ON, users can see the IdP and use it.
• When the switch is OFF, it’s as if the IdP doesn’t exist — invisible and inactive — unless hardcoded elsewhere.

Use this toggle to quickly enable/disable access without deleting the IdP configuration.

End-to-End Real-Life Example: Google OIDC Identity Provider

This is a practical example of how to configure Google as an OIDC Identity Provider in Access Management 2.0.

• Alias: google

• Display Name: Login with Google

• Display Order: 1

• Redirect URI: https://kcstk03-auth.cp.manh.cloud/realms/myrealm/broker/google/endpoint (Must be added to the Google Cloud Console OAuth client settings as an Authorized redirect URI.)

• Use Discovery Endpoint: true

• Well-Known Endpoint: https://accounts.google.com/.well-known/openid-configuration

• Client ID/Secret:
  Obtain these from the Google Cloud Console when you create the OAuth 2.0 client for Access Management 2.0:

• Client Authentication Method:
  client_secret_post (recommended for most providers)

• Client Assertion Signature Algorithm (optional):
  Use RS256 if you are configuring Private Key JWT as the authentication method.

Fields in this Interface and their definitions

• Alias: A unique identifier for the Identity Provider within Access Management 2.0.

• Display Name: The name presented to users on the login screen.

• Redirect URI: The URI where the external Identity Provider will redirect users after authentication.

• Use Discovery Endpoint: A toggle to enable automatic retrieval of OIDC configuration from the Identity Provider.

• Well-Known Endpoint: The URL used to fetch the OIDC configuration when discovery is enabled.

• Client ID and Client Secret: Credentials used by Access Management 2.0 to authenticate with the external Identity Provider.

• Client Authentication Method: The method Access Management 2.0 uses to authenticate itself to the Identity Provider.

• Client Assertion Signature Algorithm: The algorithm used when Access Management 2.0 signs client assertions.

• Mappers: Mappers in Access Management 2.0 are used to transform or transfer attributes and claims from an external Identity Provider (IdP) into Access Management 2.0’s internal user model.

• Permissions: Permissions in Access Management 2.0 define access control rules that govern who can view, modify, or manage specific Identity Provider settings and operations.

• Enabled: indicates whether the Identity Provider (IdP) is active and available for user authentication.

• First login flow: First Login Flow defines the authentication and user setup steps that Access Management 2.0 runs the first time a user logs in through an external Identity Provider.

• Post Login Flow: Post Login Flow is the authentication flow that Access Management 2.0 executes immediately after a successful login, used to enforce additional checks or actions like consent screens, condition-based role assignments, or user profile updates.

These fields are integral to setting up an OIDC Identity Provider in Access Management 2.0.
For a step-by-step guide on configuring these settings, you can refer to the official Keycloak documentation.

If you have any further questions or need assistance with specific configurations, feel free to ask!