Getting Started

1. Introduction

Authenion product from Like Minds is aimed towards delivering a secure Single Sign-On (SSO) experience for Enterprise applications from Oracle, IBM, SAP and other custom applications (java, php, .net, etc.,) that supports HTTP headers as their last mile integration and Single Sign-On. Authenion is a stand-alone product and can be installed on any physical/virtual Linux servers either on-premise/cloud or both. Authenion integrates with standard OpenID Connect providers in the market for authentication related events.

2. How does Authenion work?

Integration mechanism

Authenion as a standalone product, must be integrated with your Enterprise/Custom applications & with your Identity Provider (IdP) to complete the 'first mile and last mile integrations' for authentication and Single Sign-On (SSO). Authenion supports integration with OpenID Connect (OIDC) enabled Identity Provider and with a wide range of enterprise & custom applications.

1. The 'first mile' integration involves connecting with your identity providers, which Authenion uses to receive claims after user's authentication sessions. The claims are sent to Authenion from the Identity Provider (IdP) through OpenID Connect (OIDC) tokens.

2. The 'last mile' integration involves Authenion integration with end-user's applications where Single Sign-On (SSO) will be enabled.

3. Enterprise Deployment Model

Authenion provides a Gateway architecture for end-user's applications, that supports Header variables for last mile integration and Single Sign-On. In the gateway model, the user's request is initially directed to Authenion and then Authenion grants or denies access to the request based on the application resource protection type.

• This deployment model can be set up quickly without disrupting the applications. Authenion will be installed on separate servers from the application web servers.

• With the fewer components in the architecture, it is easy to manage. All transactions are logged, and makes it easier for security audit purposes.

4. What can I Configure with Authenion?

Authenion includes a wide range of configurations from its administration console in first-mile & last-mile integration approach. The following are the configurations we can perform in the console.

System Requirements

The following requirements should be met for Authenion installation. Authenion qualifies & certifies the following configurations, that they are compatible with the product. Authenion supports IPv4 addressing.

Launching the Authenion Admin UI Console

To launch the Authenion Admin UI console, we provide a standalone utility (authenion-admin-xx-version.zip) that can run independently of containers operating on its own server. You can launch the Authenion admin console using either the OIDC provider or the standalone mode.

1. Pre-requisites (for both Linux and Windows)

Download the File:

1. Download the `authenion-admin-xx-version.zip` file and place it in the application server where our Authenion-EIK is deployed.

Extract the File:

1. Unzip the `authenion-admin-xx-version.zip` file.

2. After extraction, you will see only one file: authenion-admin-xx-version .

2. OIDC Provider for Authentication to Launch Authenion Console

1. Open a terminal on your Linux or windows server where the `authenion-admin-xx-version.zip` file is located.

2. Make sure the `authenion.p12` file is in the same directory.

3. Use the `cd` command to go to the directory where both files are present.

4. Run the following command in the terminal to execute the utility and launch the Authenion UI Admin console:

java -jar authenion-admin-xx-version.zip com.authenion.sso.authenionadmin.AuthenionAdminApplication

--authority=https://hostname/TenantId/v2.0 --client_id=Applicationclientid --redirect_uri

=https://<authenionhostname>:9898 --scope=api://<Applicationid>/openid --prompt=login

5. Once the execution is successful, you will be redirected to the Authenion Admin Console.

Note: Please ensure that the redirect_uri used in the command is configured in the OIDC provider.

3. Using Local Authentication to Launch Authenion Console

To launch the Authenion console using local authentication instead of an OIDC provider, follow these steps:

Execute the Command:

1. Run the following Java command to enable local authentication:

java -jar authenion-admin-xx-version.zip com.authenion.sso.authenionadmin.AdminApplication

--localAuthEnabled=true --issuerUrl=https://servername:9898 --adminPassword=anypassword

Note: You can set the password using an environment variable. Ensure the password is strong, including special characters like % or $ for enhanced security.

Login Information:

1. After executing the command, use the following login credentials:

Username:Administrator

Password:The password you specified in the command (e.g., anypassword)

Console Interactions & Configurations

This section describes the UI of Authenion (Admin Console) and its interactions and provides steps for accessing and configuring it. Access the Authenion UI by clicking Administrative Console.

1. Dashboard / Applications

The Dashboard / Applications page lets you view, create, or modify the applications we protect. The total protected applications will be displayed in the Dashboard Application’s tab. It also lets you access the Identity Provider Configuration page next to the Applications tab and access the sidebar menu for other required configurations.

2. Import - Getting config-data into the UI

The Import button in the Dashboard page lets you get the data into the UI.

The Import page has two operations:

1. Fetch Function: The Fetch function is used to get the data from your Authenion Server. It automatically retrieves all the Authenion config data and makes it available in the Authenion UI. It uses the Authenion Instance plugin which is running on the Authenion server.

2. Upload Operation: The Upload operation is used to load the data from your local file system into the UI manually through any previously extracted configs.

Retrieving Config data from existing Authenion Instance

1. For first time installation & configuration of Authenion, skip this step and continue with the next section – Identity Provider Configuration.

2. If you have an Authenion server up & running already, you can bring the configuration data into the UI through the Import function.

3. Click Import in the Authenion Dashboard.

4. In the Import page, enter the detail for Authenion Instance. For example, authenion.example.com

5. Click Fetch.

6. This will bring your Authenion configuration data from Authenion server to the UI.

3. Identity Provider Configuration

The Identity Provider Configuration page allows you to connect with your Identity Provider / OIDC Token Provider. This configuration includes details such as Token Providers OAuth/OIDC endpoints, Authenion Client registration details, Claims to obtain from the Token Provider. It includes additional configuration for Authenion such as; Authenion Instance, Domain & Session duration configurations.

Adding Identity Provider Configuration

1. Click Identity Provider Configuration in the Dashboard page.

2. Enter the following details & click Save to configure your Token Provider with Authenion for authentication.

• OpenID Connect Provider - Settings

Configurations	Values
Authorization URL	https://idp.example.com/authorize
Token URL	https://idp.example.com/token
JWKS URL	https://idp.example.com/jwks
Logout URL	https://idp.example.com/idp/logout
Issuer	https://idp.example.com
Userinfo URL	https://idp.example.com/idp/userinfo  (Optional)
Audience	authenion
Client ID	Registered value client_id from your IdP
Client Secret	Registered client_secret value from your IdP
Scope	openid  (Multiple scopes can be added)
Claims	Claims from Identity Provider  (sub, username, email, etc.,)
Authenion Instances	https://authenion.example.com:8090 Note: If the Authenion is configured in cluster, enter the Authenion Instances value from all the Authenion servers. The default port is 8090 and enabled with HTTPS. This field supports multiple entries.




• Cookie Settings

Configurations	Values
Cookie Domain	example.com
Session Duration	3600

Adding LDAP Authentication Provider Configuration

1. Click LDAP Authentication Provider Configuration in the Dashboard page.

2. Enter the following details & click Save to configure your LDAP Provider with Authenion for authentication.

• LDAP Authentication Provider - Settings

Configurations	Values
LDAP Server	ldaps://ldap.example.com:636
Bind DN	Configured BindDN from LDAP
Bind Password	Configured Bind Password from LDAP
Base DN	Configured Base DN from LDAP
Search Base	Configured Search Base from LDAP
Search Subtree	checkbox
Return Attributes	Configured the Return Attributes from LDAP
Username Attribute	Configure Username Attribute
Read Timeout	3000
Client Secret	Registered client_secret value from your IdP
OIDC Virtual Server	authenion.example.com
OIDC Virtual Server Port	443
Use SSL	checkbox  (Enable/Disable HTTP or HTTPS)
Include Claims in ID_Token	checkbox  (Enable/Disable Claims in ID_Token)
Enable MFA	checkbox  (Enable/Disable MFA)




Note: Commonly supported LDAP providers are PingDirectory, Microsoft Active Directory, etc.






• MFA Settings

Email: When this checkbox is enabled, a one-time password is sent to the user's registered email address for authentication.

SMS: When this checkbox is enabled, users receive a one-time password via SMS, using Twilio integration for message delivery.

TOTP: When this checkbox is enabled, users can authenticate using time-based one-time passwords through apps like Google or Microsoft Authenticat

Configurations	Values
Email	checkbox  (Enable/Disable Email)
SMS	checkbox  (Enable/Disable SMS)
TOTP	checkbox  (Enable/Disable TOTP)

• SMTP Configurations

From Address: specify the email address used for sending notification emails.

Email Server: SMTP server for sending emails.

Mail Port: SMTP server port.

Ldap Attribute: The LDAP attribute that stores the user’s email address. This value is retrieved during authentication to send one-time passcodes (OTPs) via email.

Configurations	Values
From Address	donot-reply@example.com
Email Server	example.com
Mail Port	587 (for TLS)/465 (for SSL)
Mail Protocol	smtp/smtps
Username	example.com
Password	password
Connection Timeout	8000
Ldap Attribute	mail
SMTPS Authentication	checkbox  (SMTP or SMTPS)
Enable Encryption	checkbox  (Enable/Disable TLS or SSL Encryption)






• Twilio Settings

Account SID: A Twilio Account SID is a 34-character alphanumeric identifier unique key that is used to identify a specific Twilio Parent Account or Subaccount.

Auth token: Auth Token is a secret password, used to authenticate requests to the Twilio REST API.

SMS Service: SMS provide or service being used.

Ldap Attribute: The LDAP attribute that stores the user’s mobile number. It is used to deliver OTPs via SMS during the multi-factor authentication process.

Configurations	Values
Account SID	Registered Account SID from Twilio
Auth Token	Registered Auth Token from Twilio
From Number	Registered From Number from Twilio
SMS Service	twilio
Ldap Attribute	mobile




• TOTP Settings

Grace Time: Refers to the period after a TOTP code has technically expired during which it can still be used for authentication, allowing for minor delays in code entry. The default grace time is either 30 or 60 seconds.

Skew Windows: Refers to the allowance of a certain number of time intervals (e.g., 30-second periods) that are considered valid for authentication, even if there is a slight discrepancy between the client’s and server’s time.

Ldap Attribute: The LDAP attribute where the TOTP (Time-based One-Time Password) secret key is stored for the user. This is used to validate OTPs generated by authenticator apps like Google Authenticator or Microsoft Authenticator.

Configurations	Values
Grace Time	30 or 60
Skew Windows	1
Ldap Attribute	totpSecret

5. Sidebar

The Sidebar Menu has the following Configurations

• Applications

• Virtual Servers

• Application Hosts

• Header Mappings

• Resources

• Authenion Status

• EIK Configurator

• Logout

• Sync

• Export

6. Applications

Applications sidebar represent the protected Applications to which the user requests are sent. Each application will have a dedicated entry in the Dashboard/Applications tab. Applications are configured with Virtual Servers, Resources, Header Mappings & corresponds to a single Application Host (target application/backend server).

Adding an Application

Adding a protected application in Authenion has the following pre-requisites. Complete the setup for the below configurations before you create a new application.

• Virtual Servers (Section 6)

• Application Hosts (Section 7)

• Header Mappings (Section 8)

• Resources (Section 9)

1. To add an application, click New Application on the Dashboard page.

2. Enter the following details:




Configurations	Values
Application ID	Unique ID  (auto generated)
Application Name	App
Virtual Servers	AgileVirtualServer (Configured in Section 6 )
Header Mappings	Headers  (Configured Section 8)
Protected Resource	AgileProtected (Configured Section 9)
Excluded Resource	AgileExcluded (Configured Section 9)
Application Hosts	AgileHost (Configured Section 7)
Authenion Instances	https://authenion.example.com:8090  (auto populated)
Enable	Checkbox  (Enable/Disable Application)
Enable Host Headers	Checkbox  (Enable/Disable Host Headers)




3. Click Save to complete the configuration for a new application.

7. Virtual Servers

Virtual Servers enables you to protect multiple applications and their hosts. The Virtual Server is a combination of hostname and port number and is defined by example.com:443.

Adding a Virtual Server

1. Click Virtual Servers on the sidebar menu.

2. Click the “+ New Virtual Server” button on the Virtual Servers page.

3. Enter the following details to create a Virtual Server for your application.

For example:

Configurations	Values
ID	Unique ID  (auto generated)
Name	AgileVirtualServer
Host	authenion.example.com  (protected application domain or hostname)
Port	8443
Use SSL	checkbox   (HTTP or HTTPS)




4. Click Save to complete the Virtual Server configuration.

8. Application Hosts

Applications Hosts are the target applications or the backend application servers that Authenion is protecting through the gateway architecture. The target application’s access requests are validated by Authenion before they are forwarded.

Adding Application Hosts

1. Click Application Hosts on the sidebar menu.

2. Click the “+New Application Host” button on the Application Hosts page.

3. Enter the following details to create an Application Host for your target application server.

For example:

Configurations	Values
ID	Unique ID  (auto generated)
Name	MyAppBackend
Host	apex.likemindscloud.com:8080   (protected application/webserver details)
Use SSL	checkbox   (HTTP or HTTPS)
Enable Session Persistence	checkbox   (Enable/Disable Session Persistence)
HTTP1.1	checkbox   (Enable/Disable HTTP Proxy with HTTP/1.1 )




4. Click Save to complete the Application Host configuration.

9. Header Mappings

Header Mappings sends the User attributes to the target application after authentication. The target application will send the attributes for validation purposes. The Header Mappings will receive the user attributes from the Claims which are sent by the Token Provider. Once the claims are received, it is then made available as HTTP-Headers to the target applications.

Adding Header Mapping

1. Click Header Mappings on the sidebar menu.

2. Click the “+New Header Mapping” button on the Header Mappings page.

3. Enter the following details to create a header mapping for your target application.

For example:

Configurations	Values
ID	Unique ID  (auto generated)
Name	MyAppHeaders
App Header	OIDC Claims
USER_NAME	username
USER_MAIL	email




4. Click Save to complete the Header Mappings configuration.

10. Resources

Resources are the components/URI of the applications. The resources can be mapped as either protected or excluded resources in an application.

Adding Resources

1. Click Resources on the sidebar menu.

2. Click the “+New Resource” button on the Resources page.

3. Enter the following details to create a Resources for your target application.

For example:

Configurations	Values
ID	Unique ID  (auto generated)
Name	MyAppResources
Resource Path	/ords/**  (Resource Path starts with a ‘/’. Multiple resource paths can be added)
Enable Authorization Rules	Toggle  (Enable/Disable Authorization Rules)
Rule	The Authenion Rules Engine allows you to define and manage access policies for your applications and resources. It enables precise control over user access conditions and content modifications.  (optional)




4. Click Save to complete the Resources configuration.

11. Authenion Status

The Authenion Status page shows the health of the Authenion Instance that is running in the Authenion server. This status page also displays your authenion license information.

1. Click Authenion Status on the sidebar menu to view the status of your Authenion application.

12. Sync & Export

Sync

The Sync is a manual operation that lets you push all the configuration data from the Authenion UI back to the Authenion server. When you install Authenion for the first time, there will be no configuration data in the UI or in the Authenion server. The Sync operation should be triggered for both new configurations & modifications that we perform in the Authenion UI. Any changes which are not pushed from the UI to Authenion server will not be reflected until Sync operation is triggered manually.

Note: Add the JWKS endpoint to the 'agent-authorization.properties' file in the '/config/' directory.

The Sync status will throw an error status when it can't reach the Authenion instance in the Authenion server.

Export

The Export button is a quick operation that lets you download the current configurations from the UI. The exported data will be in the format of a JSON file. This file acts as a backup for the Authenion configuration data. The downloaded file name is export.json.

13. User-Customized Templates

Email Page Templates

Authenion enables customization of user-facing pages, such as emails and forms, using HTML, CSS, JavaScript, and localization files with dynamic placeholders for messages and user-specific data.Templates are located in /config/html/emailTemplates and localization messages in /config/html/locale/messages_en.properties.

1. email-forgotUsername.html

Purpose:This email template is sent to users who have forgotten their username.

Use:This email is sent when a user requests account recovery. It provides the username(s) associated with the registered email address, enabling the user to log in without creating a new account.

2. email-otpMessage.html

Purpose:This email template is used to send a One-Time Password (OTP) to users during login process.

Use: As part of multi-factor authentication (MFA), this email sends a one-time password (OTP) to verify the user’s identity and ensure secure login.

3. email-passwordChanged.html

Purpose:This email template is sent to confirm that the user’s password has been successfully changed.

Use:This email confirms the password change and helps detect unauthorized activity. If the password change wasn’t requested, it alerts the user to take immediate action to secure their account.

4. email-resetPassword.html

Purpose:This email template is used to send a password reset link to the user’s registered email address.

Use:This email provides a time-sensitive link to help users securely reset their password when a user forget their password or want to create a new one.

Login Page Templates

Login page templates in Authenion are located at <authenion_install_dir>/config/html/. These templates control the appearance of user-facing pages such as the login screen, forgot password form, and logout confirmation. You can customize these templates to match your branding and support multiple languages using message properties in the <authenion_install_dir>/config/html/locale/messages_en.properties file.

1. login.html

Purpose:This is the main login page where users enter their LDAP username and password.

Use:This page authenticates users by submitting their credentials to the server and provides links to reset a forgotten password or recover a username.

2. forgotPwd.html

Purpose:This page allows users to request a password reset link by entering their username.

Use:It sends a password reset email to the user with a time-limited link, allowing them to securely update their password.

3. signout.html

Purpose:This page is displayed after the user successfully logs out, confirming the logout action.

Use:It confirms the successful logout and provides a link to return to the homepage.

4. updatePassword.html

Purpose:This page allows users to set a new password after clicking the reset link sent to their email.

Use: It enables users to securely update their password, verifies that both passwords match, and submits the data to the server via AJAX. CSRF protection is included to ensure the request is secure and valid.

5. forgotUsername.html

Purpose:This page allows users to recover their forgotten username by entering their email address.

Use:The user submits their email address, and the system sends their registered username to the provided email address.

6. changedPwd.html

Purpose:This page is displayed after the user successfully changes their password.

Use:It notifies the user that their password has been successfully updated and provides a link to redirect them to the login page.

7. changePwd.html

Purpose:This page provides a form for users to change their password by entering their current password, new password, and confirming the new one. It includes validation to ensure the new passwords match.

Use:It allows users to update their password. After submission, the password is changed if successful, and appropriate success or error messages are displayed.

8. deviceRegistered.html

Purpose:This page confirms successful registration of an authenticator app for two-factor authentication (2FA). It displays a checkmark icon, a success message, and a "Close Window" button.

Use:This page appears after the authenticator app is successfully linked to the user account. It confirms completion of the registration and includes a "Close Window" button for the user to exit and continue using the application.

9. deviceOtp.html

Purpose:This page provides a secure OTP input form for verifying a user’s identity during multi-factor authentication (MFA). It supports TOTP and device-based methods like SMS or email, showing masked details to indicate the delivery method.

Use:This page appears when the user needs to enter a 6-digit OTP sent to their registered device or generated by an authenticator app. The user enters the code in separate fields, and upon submission, the OTP and device ID are sent to the server via AJAX for verification. If successful, the user is redirected to the /mfa/registered confirmation page; otherwise, they are redirected to /mfa/commit.

10. deviceSelection.html

Purpose:This page allows users to select a method for Multi-Factor Authentication (MFA), such as SMS, Email, TOTP. Once an option is selected, it is stored and a "Proceed" button appears for the user to continue.

Use:This page is part of the authentication process, allowing users to choose their MFA method. After selection, the form is submitted with the device ID to verify the method and continue to the next step.

11. enrollDevice.html

Purpose:This page is used to enroll a user in Multi-Factor Authentication (MFA). It displays a QR code for scanning with an authenticator app or allows manual entry of a secret key. After scanning or entering the key, the user submits the form to verify their OTP.

Use:This page is shown during the MFA enrollment process, where users set up an authenticator app by scanning the QR code or entering the secret key. After setup, the user proceeds to verify their OTP to complete the enrollment.

12. error.html

Purpose:This page displays a basic error message when an unexpected issue occurs, informing the user of the problem and advising them to try again later. It serves as a fallback page when something goes wrong in the system.

Use:This page handles unexpected errors or system issues, informing the user that something went wrong and advising them to try again later. It serves as a generic error page when no specific error message is available.

Connect with your Identity Provider

This configuration section is the 'first mile integration' of the Authenion integration mechanism. This section guides you to configure Identity/Token Providers in the Authenion administration console. The integration will be established through OAuth and OpenID Connect protocols.

1. PingFederate as the Token Provider

  Pre-requisites

• PingFederate application with IdP and OAuth/OIDC roles enabled.

• Authorization server setup in PingFederate OAuth server setting.

• A configured Ping Federate IdP adapter and/or authentication policy contract policy if required for authentication and grant mapping.

  OAuth / OIDC Configurations

 This setup will manage the configurations related to the OAuth client.

1. Create a new Client in PingFederate for Authenion.

Configurations	Values
Client Name	Value to identify Client in PingFederate
Client ID	Unique value to identify clients in PingFederate
Client Secret	A secret value known only to this Client and PingFederate
Redirect URIs	https://<authenion.example.com>:<port>/ssolibrary/oidc/callback
Bypass Authorization Approval	Enable checkbox for bypassing authorization consent screen
Allowed Grant types	Enable Authorization Code checkbox
Default Access token manager	Select the access token to map with this client
OpenID Connect Policy	Select the OpenID Connect policy created earlier




2. Review the Client configurations and click Save.

3. Map an OpenID Connect Policy to this Client with the following information:

For example:

In OpenID Connect Policy Management tab, create/modify the policy and add the attributes that need to be sent through id_token and userinfo endpoint.

Add the following attributes that need to be returned in the id_token and/or as claims through userinfo endpoint.

• username
• email

The above attributes can be mapped with their respective Scopes in the next page. For example, openid scope.

4. Replicate the configurations if PingFederate is configured in a cluster.

2. Microsoft Entra ID (formerly Azure Active Directory) as the Token Provider

  Pre-requisites

• Azure account with valid subscription.

• App registration.

• Client Secrets and Claim mappings.

  Entra ID Configurations

The following will register Authenion as an OAuth/OIDC client application in Microsoft Entra ID (formerly Azure Active Directory) & establish a unidirectional trust relationship between Authenion and Microsoft identity platform. When the registration finishes, the Azure portal displays the Authenion application registration’s overview pane. You can find the Application ID which will also be used as the client_id when we connect Authenion & Entra ID through OAuth/OIDC.

  App Registration

1. Login to the Azure portal.

2. In the Manage Microsoft Entra ID (formerly Azure Active Directory) section, click on view.

3. Click on +Add and then click on App Registration.

1. Give a display name for the app.

2. Select the tenant in which you want to register the Authenion application.

3. Add the following Authenion URI in the Redirect URI field. This is the location where Entra ID redirects the user’s request post authentication.

Redirect URI: https://<authenion.example.com>/ssolibrary/oidc/callback

4. Click on Register.

  Token Configuration

1. From the side menu, click on Token configuration.

2. Click on + Add optional claim.

1. Select ID

2. Check the attributes - email, preferred_username.

3. Click on Add.

Note: In case a dialogue appears, check the box which says Microsoft graph.

  API Permissions

1. From the side menu, click on API permissions.

2. Click on + Add a permission.

3. Click on Microsoft Graph.

4. Click on delegated permissions.

1. Under "Openid permissions", check email, openid and profile.

2. Under "User", check "User.Read".

5. Click on Add permissions.

  Certificates & Secrets

1. From the side menu, click on Certificates & secrets.

2. Click on Client secrets.

3. Click on + New client secret.

1. Enter some description for the client.

2. Set the expiry for the client.

4. Click on Add.

  Configure Azure

1. In the Azure portal, under the registered Authenion Application, configure the redirect URL for the admin UI jar.

2. Ensure the associated port is configured.

3. Example URL: `https://servername:9898`

3. Keycloak as the Token Provider

  Pre-requisites

• Admin access to the Keycloak Administration Console.

• Create Realm for your application (optional).

• If using HTTPS, a valid SSL certificate is configured to secure communications (recommended for production).

  OAuth / OIDC Configurations

 This setup will manage the configurations related to the OAuth client.

1. Create a new Client in Keycloak for Authenion-EIK.

Configurations	Values
Client Type	Select OpenID Connect
Client ID	Unique value to identify clients in keycloak
Name	Value to identify Client in Keycloak
Client authentication	Enable the toggle to client as a confidential client
Authorization	Enable/Disable fine-grained authorization support for a client
Authentication flow	Select Standard Flow (Authorization Code Grant)
Valid redirect URIs	https://<hostname>:<port>/EBSAuth/handler




2. Review the Client configurations and click Save.

3. After saving the client configuration, Keycloak will generate a Client ID and a Client Secret.

4. Navigate to the Credentials tab to obtain the Client Secret, which is used for secure backend communication with the OIDC application in Keycloak.















  Mapping User Attributes to Tokens in Keycloak

1. In the Keycloak Admin Console, go to Client Scopes. Either select an existing scope (e.g., profile) or create a new custom scope if needed.

2. Under the selected Client Scope, open the Mappers tab and add a new mapper for each attribute.

Example – Add Email Attribute

• Set Mapper Type to User Attribute
• Set Token Claim Name to email
• Enable inclusion in ID token, Access token, and User Info (optional)






3. Go to Clients, select your client, and assign the scope under either Default Client Scopes or Optional Client Scopes.