Forgot Password & Unlock Account

Cymmetri user may need assistance to Unlock Account in case their ID is locked for access. In the case where user has forgot the password, the user can self reset to gain access to Cymmetri Cloud.

Steps to Reset Password

Step 1 - Click on the Forgot Password / Unlock Account link.

Step 2 - Provide the Username in the prompt and click Next button.

Step 3 - Select the appropriate MFA option for verification

The available options visible to user depend on the MFA options enabled by the Cymmetri Administrator and the options registered by the user.

If MFA option is not registered, the user must contact the Cymmetri Administrator for further assistance.

Step 4 - Verification by MFA

Step 5 - Select Reset Password option

Step 6 - Provide password

Step 7 - Login with password reset successfully

Steps to Unlock Account

Step 1 - Click on the Forgot Password / Unlock Account link.

Step 2 - Provide the Username in the prompt and click Next button.

Step 3 - Select the appropriate MFA option for verification

The available options visible to user depend on the MFA options enabled by the Cymmetri Administrator and the options registered by the user.

If MFA option is not registered, the user must contact the Cymmetri Administrator for further assistance.

Step 4 - Verification by MFA

Step 5 - Select Unlock Account option

Step 6 - Login after account unlocked successfully

A consolidated list of all known Cymmetri error codes and their summary understanding

Accessing the Applications Menu

Applications menu in the administration page displays the various options pertaining to the Application Management processes.

Applications menu may be accessed by two ways -

Identity Hub

Image: Accessing Applications Menu from the Identity Hub

2. Click on the Identity Hub icon on the left side bar.

3. Click on the Applications text on the slide out bar.

Single Sign On Module

Image: Accessing the Single Sign On Module from the Products Menu

2. Click on the Products menu icon on the left side bar.

3. Click on the Single SignOn Module icon in the popup list.

Image: Accessing the applications submenu

4. Click on the Applications text on the slide out bar.

Understanding the applications supported by Cymmetri

Applications supported by the Cymmetri Identity platform fall majorly into three categories -

Adding Application

Once you have chosen the application to be added from the above categories, you are ready to add a new application.

Image: Applications Menu

1. Click on the “Add New” button on the top-right corner in the Applications menu.

Image: Add New Application Sub Menu

2. In the Add New Application screen, you may search for your desired application (e.g., Active Directory), or your desired connector (e.g., REST) or choose the “Custom” application type from the available application catalogue.

Image: Searching for application or connector in the Application Catalog

3. Now click on the tile shown in the list below to open the right slide out menu for renaming application as shown below.

4. Add your custom label (if you wish) in the text box and click on the “Add Application” button.

Image: Application Added

Conclusion

To access Cymmetri, user must use a web browser such as Google Chrome or Safari and type the appropriate address.

Sign In to Cymmetri

Steps to access Cymmetri

Below is a step-by-step guide for accessing Cymmetri:

Step 1 - Type the appropriate URL in the browser address bar.

What is Cymmetri?

Cymmetri is a well-trusted platform acting as an advisor and an end-to-end partner for Security-aware teams looking to deploy Identity and Access Management Solutions across their organization. We offer an industry-standard product backed by a strong team that always aims to innovate our solutions to cater to a wide variety of enterprise needs.

Cymmetri User Login flow starts with the process of a user accessing their tenant instance login page.

Typically, this would be of the format, https://<company-name>.cymmetri.io

Once, on the Cymmetri Login page, please enter your username (you should have received this on your corporate email).

Enter the username received on the mail, and click on the Next button.

If your administrator has enabled password-less login option, then you will be able to see the Login without password button, else you will see the login button.

The step below indicates the trigger for the Password-less login flow.

Clicking on the "Login without password" button will trigger the password-less login flow, will prompt the registered multi-factor authentication options for login.

The step below indicates the trigger for the Password-based login flow.

Enter the password for your user account and click on the Login button to proceed with the password-based login flow. Depending on whether the administrator has enabled the multi-factor authentication options for your organization, and depending on the factors that you have registered for, you will be shown login options.

The steps below for choosing multi-factor authentication options are common for the password-less login and password-based login flows.

Option 1 - Choosing Cymmetri Authenticator will require you to enter your Time-based OTP as it appears on your Cymmetri Authenticator mobile application. Enter the TOTP and click on Verify to continue.

Option 2 - Choosing Push Authenticator will send a push notification to your mobile phone and you may click on the accept button to complete the login process.

Option 3 - Choosing Google Authenticator will require you to enter your Time-based OTP as it appears on your Google Authenticator mobile application. Enter the TOTP and click on Verify to continue.

Option 4 - Choosing SMS Authenticator will send an OTP to the user's registered mobile number and the user is expected to enter this OTP and Click on Verify to continue.

Regardless of the flow followed and the multi-factor authentication option chosen, the user will end up on the dashboard page below upon successful login.

Cymmetri Identity platform supports login using multi-factor authentication options as -

1. a second factor of authentication for the password-based login process.

2. a method of authentication for the password-less login flow.

The following steps indicate how to set up multi-factor authentication options in your Cymmetri Identity platform instance for both flows

Cymmetri allows flexibility by introducing both modern mechanisms, such as -

1. Time based OTP (through Cymmetri Authenticator mobile application)

2. Time based OTP (through Google Authenticator and other mobile application)

3. Push based Notification (through Cymmetri Authenticator mobile application)

4. SMS OTP

5. Email OTP

In this document, we will go through setting up the Multi-factor authentication options on the Cymmetri Identity Platform, and run through the setup of Multi-factor authentication options and their usage for the login scenario.

Setting up Multi-factor Authentication for the tenant

1. Access Multi-factor authentication by going to Products menu > Multifactor authentication product

2. Next, we select factors sub-menu

3. We now select the Cymmetri Authenticator (Time based OTP) toggle and click confirm to setup Cymmetri Authenticator as an MFA option

4. Similarly we toggle on the Push Notification and SMS Authenticator (OTP) options

5. Next we select the configuration sub-menu to configure the OTP options, here we will enable the Email OTP option by toggling it on.

6. Next we move to configure the rules for Multi-factor authentication policy for login

7. Click on the pencil icon to start editing the policy and change the dropdown of all factors to indicate that they are mandatory (required).

Let us talk about the options available for each factor -

Required - This setting means that the corresponding factor is required to be enabled for each user, and every user must set up this factor in their next login.

Optional - This setting means that the corresponding factor is not required to be enabled for each user, and they may configure this option from their "My Workspace". Once the user configures it, they may use it for the purpose of second level of authentication during authentication. Disabled - This settings means that the corresponding factor is not required or enabled for each user, and the user may not configure or use it for authentication into the Cymmetri platform.

8. Now click on the pencil icon in the upper box to toggle on this rule.

9. All subsequent logins of any user on the Cymmetri Identity platform will now require the use of mandatory MFA for one of these factors.

The following steps indicate how to set up for Password-less login

As an organization or domain administrator, click on the products menu on the left-hand side, and then click on the passwordless button to start configuring password-less authentication option.

Click on the toggle button on the top to enable the password-less login option for the end-users logging into the Cymmetri Identity platform tenant.

Further, as an administrator you may turn on/off the toggle switches to allow/block the end-user from using a particular multi-factor authentication option during password-less login.

1. TOTP Based - refers to the Cymmetri Authenticator option as indicated earlier in the document.

2. OTP Based - refers to the SMS Authenticator option as indicated earlier in the document.

3. Consent Based - refers to the Push Authenticator option as indicated earlier in the document.

1. Start by clicking on the link to start the registration of your tenant on the Cymmetri Cloud 2.0 and enter your personal details with your work email. Click on Next.

1. Enter your country, phone number (mandatory to receive OTP), and enter a domain name for your tenant. In case the domain available message is not shown, choose a different domain name. Click on Start trial button.

1. You will receive an OTP on your mobile number from the previous step. Enter the OTP here and wait for a few seconds for your tenant to be created.

1. You will be redirect to your domain to create a new first Organization Admin User. Ensure that your password matches the password policy.

1. You will receive a message to show that your tenant has been created.

1. Click on the login button for proceeding with the onboarding process

1. Click on the Next button to enter your password and proceed with the setup of your tenant.

1. Choose applications from the application catalogue, click on the application icon. Then click on the Next button.

1. Enter details to create a second administrator account. Click on Send Invite button to create an administrator. Click on Next button to proceed.

1. (Optional) Add users if you wish to. Then click on finish.

1. You will be redirected to the Dashboard to proceed with the system.

Next Steps

Report Listing

Report Scheduling

Listing of external Identity Providers

Configuring Google as an external Identity Provider

Cymmetri provides a bird’s eye view to user of all the user’s that report to.

Cymmetri supports the following web browsers.

Version of specific browsers supported by Cymmetri.

Cymmetri provides an interface where users can view the applications assigned to the logged in user from where the user can access such applications using Single Sign-On (SSO). The SSO ensures that users do not need to remember the username and password to access the desired application.

The users can also request for access applications not yet assigned / entitled to them by providing the necessary information before being granted access.

Application

The Application section under My Access provides user easy and friction-less access to the applications they want to use. Applications can be assigned to the user using the Cymmetri Provisioning framework, either as a birth-right (default) access, or through Provisioning Rules as defined by the Administrator. For applications where an approval is required, the Cymmetri Workflow processes such access requests before granting access to the user.

Search an application

The search bar on the Application page allows users to quickly search an application by its name. To use the search, click on the search icon followed by typing the name of the desired application.

The search result is automatically displayed for the matching applications below

The search for applications is across the tags defined by the user.

Performing SSO

The user can access any application by simply clicking on the desired application tile. Cymmetri will initiate the authentication request to the target application, and here, the user will get authenticated to the desired application in a new browser tab or window.

User accessing the applications which are assigned time bound basis, will show a snippet defining the access period. This is for the user’s information. The snippet is visible while user hovers over the application tile.

Managing application options

As a user self-service action, applications assigned to the user can provide the user with options to manage their access. Clicking on the menu button under an application tile opens a context menu for that application.

Setting

Under the setting context menu, the user can view the current Role assigned to user, and if configured by Administrator, the user can change or request for change the role assigned to them.

Revoke Consent

User can self revoke the consent granted at time of authentication with specified applications. This consent is required when user authorizes Cymmetri to capture certain user attributes.

The system will warn that the action cannot be undone.

After the user’s confirmation, Cymmetri will remove the consent granted for storing the user attributes.

The consent revoked by the user, may be essential for accessing the application via Cymmetri. At the time of next authentication of the application, the consent will be requested again and the user can choose to provide the same.

Request Extension

Cymmetri allows user to extend their access period for applications with time-bound access.

The user can opt the Request Extension option from the application context menu.

Cymmetri shows the current access end date. The user is required to select a new access end date and click on Request button.

On successful submission, the user can view the success message.

Copy to Tag

Managing Tags

The user is allowed to create Tags to manage the applications assigned into different sections for ease of access.

Create a tag

To add a tag, click on Create New Tag button. Provide the desired name and click on Create button.

Once submitted successfully, the tag is visible on Application page.

User can create up to 4 tags. After user creates the fourth tag, the Create New Tag button is disabled.

A user cannot create a tag with an existing tag name. Cymmetri will show an error Tag with same name already exists.

Copying applications to a tag

User can copy applications from the All Applications section to any tag as desired. Click on the menu button inside an application tile, select the option Copy to Tag.

Once the tag is clicked, the system will copy the application to the respective tab and user will see the sucess message.

User can now view the application under the tag by clicking on the tag name.

User can move an application from one tag to another tag by following the above mentioned process.

Editing a tag name

User can rename a tag anytime by clicking on the menu button on the tag and selecting Rename option.

Type in the revised name for tag and click Update button.

On successful update, the tag name is changed and user can see the success message.

Deleting a tag

User can opt to delete a tag using the the delete tag option on clicking the Delete option.

Clicking on Delete will remove the tag immediately. On successful delete, the tag is removed and user can see the success message.

Deleting the tag will not remove the applications assigned to user. The applications can always be viewed under All Applications.

Request

User can view the available applications after click on the Request button on the Application page under My Access.

Search

The user can search all applications under Request by typing the required application name under the search box on top right corner.

The user can view all the applications that are available for the organization. The applications already assigned to the user are indicated by a green check mark.

The user can request for any application not already assigned to them by clicking on the required application tile.

The search can be used to quickly navigate to any application the user wants to access.

The user is required to select the period of access - either a Start and End Date for access or opt for Lifetime Access. After the selection, the user can submit the request by clicking the Save button.

Depending on the configuration performed by the Administrator, the user will be assigned to the application or the approval request for the user’s access will be initiated.

After all the approvals are granted, the user will be assigned to the application.

The Dashboard under My Workspace is the default page once the user has logged in to Cymmetri. This page is accessible to all users in Cymmetri.

Cymmetri assigns a basic user role to all users in the system be default. All users with such a role will be able to view the screen as below-

For users with a Cymmetri Administrator role will be able to view additional system information on the dashboard. An example dashboard view of a Cymmetri Administrator user -

Cymmetri Administration activities can be performed by users with different roles which can be assigned. The screen above

Recently Used Applications

The user sees a summary of the recently accessed applications and click on any of the application will result in SSO to such application. The system will show No recent apps if there are no applications accessed by user.

Access Expiring

The user is notified about the applications where the access will be automatically revoked after the stipulated time is over. The applications visible under this section are those whose access time is defined for the user and not provided as lifetime access to such user.

Running Certifications

The user sees a summary of the certification campaigns which are currently active. The user may require to provide access confirmations for continuing access of other Cymmetri users by either approving or revocation of such access. A click on the active campaign will lead the user to the Access Review section of Cymmetri My Workspace.

Requests

The user sees a summary count of requests that require logged in user’s attention. Access requests requiring the user’s confirmations are listed in the Inbox section of Cymmetri My Workspace. A quick reference of the available options are:

• Pending Requests

• Application Requests

• Claims

• New Applications

• New Joinees

User can click on See All which will lead the user to Team section of Cymmetri My Workspace. The system will show count as zero is there are no new pending requests for the user. For each new unread request, the system will indicate the count in the orange box.

Cymmetri Cloud allows all users to be able to perform self-service actions such as Single Sign-On, password reset, MFA reset, Approve access request for other users, Re-certification approvals among others.

Cymmetri My Workspace is the central console where such user actions can be performed from.

User Navigation

From the Dashboard page of Cymmetri My Workspace, the user can navigate to different sections of Cymmetri from the main navigation panel - the menu.

Users will administrator privileges will be able to see additional menu items above the My Workspace menu section called Admin.

Administrator user can navigate from their My Workspace to Admin section and vice-versa by clicking on the appropriate Main Menu Navigation link.

Accessibility options & Settings

The logged in user can access the Settings page by clicking on the user menu on the header.

Under the Settings sub-menu, the user can-

• View their Profile

• Change Password

• Manage Additional Verification (MFA)

My Profile

Change Password

The logged in user can self change the password using the Change Password sub-menu.

Additional Verification (MFA)

A logged in Cymmetri user can self mange the Cymmetri Multi-Factor Verification options enabled by the Cymmetri Administrator. The user can see the list of available options and can remove and setup these options as needed.

Logout from Cymmetri

A Cymmetri user can be logged out either by the system through the time-out policy, or the user can logout using the My Workspace logout options as shown below-

Logout from User menu option

Logout from Main Menu navigation option

Dashboard

The Dashboard under My Workspace is the default page once the user has logged in to Cymmetri. This page is accessible to all users in Cymmetri.

Cymmetri assigns a basic user role to all users in the system be default. All users with such a role will be able to view the screen as below-

For users with a Cymmetri Administrator role will be able to view additional system information on the dashboard. An example dashboard view of a Cymmetri Administrator user -

Cymmetri Administration activities can be performed by users with different roles which can be assigned. The screen above

Recently Used Applications

The user sees a summary of the recently accessed applications and click on any of the application will result in SSO to such application. The system will show No recent apps if there are no applications accessed by user.

Access Expiring

The user is notified about the applications where the access will be automatically revoked after the stipulated time is over. The applications visible under this section are those whose access time is defined for the user and not provided as lifetime access to such user.

Running Certifications

The user sees a summary of the certification campaigns which are currently active. The user may require to provide access confirmations for continuing access of other Cymmetri users by either approving or revocation of such access. A click on the active campaign will lead the user to the Access Review section of Cymmetri My Workspace.

Requests

The user sees a summary count of requests that require logged in user’s attention. Access requests requiring the user’s confirmations are listed in the Inbox section of Cymmetri My Workspace. A quick reference of the available options are:

• Pending Requests

• Application Requests

• Claims

• New Applications

• New Joinees

User can click on See All which will lead the user to Team section of Cymmetri My Workspace. The system will show count as zero is there are no new pending requests for the user. For each new unread request, the system will indicate the count in the orange box.

My Access

Using Cymmetri, user can access the applications assigned to them seamlessly. The access defined for the user (also called entitlements) allows the user to authenticate without the need of username and password of the target application.

Users can tag the applications assigned to them and perform other self service activities.

Users can also request for applications not already assigned to them by clicking on the Request button. Here the user can see the list of resources available for request by the user.

Inbox

Cymmetri users can approve the access of other users through the Inbox section in Cymmetri My Workspace. The users who are mapped as approver, receive the approval request in their Inbox, where the request can be authorized or rejected with appropriate comments.

The user can also view the status of previous requests under the Archive section. Under Claims, the user can view the requests which are mapped to Cymmetri Groups, where the user will be part of such an approver group.

The user can also view the request for access raised by them under My Requests.

Access Review

As part of Cymmetri My Workspace, users can review the on-going access of other Cymmetri users, provided they are assigned to review the access of such users.

Cymmetri Campaigns which are currently active appear for the user to click and review the access grants.

This feature is coming soon!

Team

For Cymmetri users who are reportees of the logged in user, the system shows such reportees as a grid or a list. The manager user, can view the assigned application of the reportee. The manager user can also view the risks associated with the access entitlements of the reportee.

Understand how to add and manage your cloud and on-premise applications through your Cymmetri Identity platform deployment. Your Cymmetri Identity deployment allows you to manage your cloud-based applications and on-premise applications from a single administration console.

Adding Applications

Understand how to add the applications used by your organization, to be managed your Cymmetri Identity platform deployment. Use the FAQ to learn how to add applications to be managed in the deployment.

Single Sign On

Single Sign On is the process of ensuring that once an end user is logged onto the Cymmetri Identity platform, they should be able to seamlessly move their session to any of your applications managed by your Cymmetri Identity platform deployment. Use the FAQ to learn how to configure Single Sign On for your application.

Managing the Application Sign On Policy

Modern IAM deployments wishing to have progressive authentication may require some critical application integrations within your deployment to perform additional authentication while performing Single Sign On for the end user. Use the FAQ to learn how to configure the Application Sign On Policy.

Provisioning

Provisioning refers to the process of creating, modifying, and in general pushing the user account information stored on the Cymmetri Identity platform to the applications managed by your Cymmetri Identity platform deployment. Use the FAQ to learn how to configure User Account Provisioning.

Reconciliation

Reconciliation of User accounts is a primary activity in Identity Governance, which allows for synchronisation between the user account information on the managed application and the Cymmetri Identity platform deployments, including provisioning, modifying, deprovisioning, and modifying user account attributes based on various synchronisation states. Use the FAQ to learn how to configure the Identity Reconciliation Process.

Assigning Application

Once an application has been added to the Cymmetri Identity platform deployment and the necessary configurations for Single Sign On, Provisioning and Reconciliation have been performed, an application may be assigned to an individual user or to a group of users. Use the FAQ to learn how to assign application to a user.

Once the managed application has been added to your Cymmetri Identity platform tenant, you will be able to assign applications to your end-users.

User Assignment Scenarios

There are three ways in which users may be assigned to users -

1. Admin may assign an application directly to a user.

2. Admin may map an application to a group; and the user is added to the group or is already part of the group.

3. End User may request an application and is granted access to the application.

Flows of Scenarios

There are flows in which is user is assigned to the application

Admin assigns an application directly to the end user

Users of the Cymmetri Identity platform deployment having admin roles among Organization Admin, Domain Admin, and Application Admin, will be able to assign an end-user to a managed application.

First, we need to add the application to the Cymmetri Identity platform deployment for managing it through Cymmetri deployment.

Next, we move to configure the application to assign it to an end user.

Click on the application tile to configure it.

The flow for assignment goes as follows -

Flow Description

1. Admin clicks on the application tile, and starts the configuration.

3. Click on the “assign new” button on the users menu.
5. We see the following fields here -

   1. Start Date - When the user will be assigned the application.

   2. End Date - When the user will be deprovisioned from the application.

   3. Lifetime Access - If selected, the user will be assigned the application for the entire duration that they are active in the Cymmetri Identity platform.

   4. Dynamic Form Fields - Dynamic form fields may be configured by the admin and enabled to allow the administrator to add more user attribute fields.

      1. Preferred Username - Mandatory text field

      2. Request Additional Modules - Optional Radio button

8. This step shows that the workflow has been initiated for the user. This is because, we have enabled the workflow for application provisioning (user assignment) for this managed application.

11. The approver may change the start and end date, if required; refer to the dynamic form attributes passed during the application assignment.

12. Let us click on accept to continue the flow.

14. Let us click “Accept” to proceed.

15. After the last level approver has also approved the assignment, the backend processes will run the application provisioning flow.

16. Once the user has been provisioned in the application, they will be able to see it in their list of applications.

Admin assigns an application directly to a group

Users of the Cymmetri Identity platform deployment having admin roles among Organization Admin, Domain Admin, and Application Admin, will be able to assign an entire group of users to a managed application.

First, we need to add the application to the Cymmetri Identity platform deployment for managing it through Cymmetri deployment.

Next, we move to configure the application to assign it to a group.

Click on the application tile to configure it.

The flow for assigning a group to an application goes as follows -

Flow Description

1. Admin clicks on the application tile, and starts the configuration.

2. Click on the assignments tab on the left hand side menu.

3. Click on the “Assign New” button in the groups section.

4. Search for the group you wish to assign the application to and click on the assign button.

6. Viewing the application tiles, we can see if the user was directly assigned the application or received access by the virtue of being part of a group.

User requests for an application

Users of the Cymmetri Identity platform deployment will be able to request for access to a managed application.

The flow for an end-user to request for an application is as follows -

Flow Description

1. User visits their “My Workspace” menu.

2. Click on the “My access” left-hand side menu.

5. We see the following fields here -

a. Start Date - When the user will be assigned the application.

b. End Date - When the user will be deprovisioned from the application.

c. Lifetime Access - If selected, the user will be assigned the application for the entire duration that they are active in the Cymmetri Identity platform.

d. Dynamic Form Fields - Dynamic form fields may be configured by the admin and enabled to allow the administrator to add more user attribute fields.

i. Preferred Username - Mandatory text field

ii. Request Additional Modules - Optional Radio button

3. This step shows that the workflow has been initiated for the user. This is because, we have enabled the

workflow for application provisioning (user assignment) for this managed application. The workflow approver will then receive a request to approve the user assignment in their inbox.

Now the approver may approve or reject the user assignment

The approver may change the start and end date, if required; refer to the dynamic form attributes passed during the application assignment. Let us click on accept to continue the flow. Now the next level of approver will be able to see the previous levels of approval, and similar to the previous level of approval, the approver may change the start and end date, if required; refer to the dynamic form attributes passed during the application assignment.

Let us click “Accept” to proceed. After the last level approver has also approved the assignment, the backend processes will run the application provisioning flow. Once the user has been provisioned in the application, they will be able to see it in their list of applications.

Dynamic Form

Dynamic Form allows the administrator to request additional fields from the administrator or the end user assigning the applications to collect additional user fields to be used for provisioning the user into the managed application.

Creating a dynamic form

Creating a dynamic form involves the administrator configuring the managed application by clicking on the left-hand side menu item “forms”.

You may now load the default form by clicking on the “Load Sample form”

You may now edit the default form, a preview of the form will be shown on the right hand side.

Let us imagine a simple form that can capture “Preferred Username” [text field] and “Request Additional Modules” [Radio] with two options “Admin” and “Readonly”.

Click on the save button.

Now click on the “Confirm” button in the popup to enable the form for the application.

The Cymmetri application workflow mechanism is used to enforce approval of users access requests for the purpose of right-user-getting-correct-access. At the same time, providing a history of all such requests and their approvals ensures accurate reporting.

The Cymmetri Inbox section allows users to view and approve the access requests for other Cymmetri users. Apart from user access approval requests, the user can also view the status of their own access requests under My Requests section.

My Requests

The My Requests section lists all the application access requests raised by the logged in user. Here the user can view the status of the application access requests raised and review the access grant history.

Open

The Open menu lists all the requests yet to be approved for the user.

Closed

The Closed menu lists all the requests that have been either approved or rejected for access.

By clicking on one of the mail list items, the user can view the history of the task. The details of the approve or reject action can be seen with the time and date of such an action as well as the comments of the approver if any.

Requests

The Requests section under Inbox lists the application access requests raised by other Cymmetri users.

Requesting for an application

Cymmetri users can request for access to applications not automatically assigned to them. The request process is managed from My Access > Request section.

The request for application access may not always require an approval. In certain cases the access request will be automatically applied as there is no approval workflow configured by Cymmetri Administrator.

Approving an application request

After a Cymmetri user has raised an approval request, the approver authority is selected by Cymmetri automatically. The approver is alerted by the system through an notification event in the user’s Notification tray. Cymmetri can also alert the approval user by way of email sent to the user.

The user can also view the notification request under Request section on the user’s Dashboard.

By clicking on the notification or the Application Requests short-link, the user is sent to the Inbox page. Here the user should click on Open menu under Requests section to view all the pending application access requests.

On clicking one of the mail list items, the user can view the details of the application access request.

The approval user can now approve the request or mark their rejection for the access request. The approval user may provide comments for the action taken under the Comment box text area.

After clicking the Accept button, the user approves the application access request. Cymmetri shows the success message to the approval user.

Viewing application request history

Cymmetri users can view the history of processed requests by way the Archive menu under Requests section. The user can click on any one of the mail list items, and view the details of task.

If an access request requires more than one level of approval, the same can be viewed one below the other with the following details -

• Approver Name

• Date and Time of approval

• Approver comments (if any)

Requesting change in application access

Cymmetri users can request for change in access role for applications assigned to them. The request process is managed from My Access > Application > Setting context menu. An approval request is generated once the user submits the role change request.

The role change may not always require an approval. In certain cases the role change will be automatically applied as there is no approval workflow configured by Cymmetri Administrator.

Claims

Claims is the process of approving user access requests through any one approving authority in Cymmetri. In the event one approver is unavailable, it is likely other approver(s) can stake claim for the request and process the access request.

The approvers are configured by the Cymmetri Administrator. The approver level level can be defined as a single user, reporting manager or a group of users.

A claim request can be access from the Dashboard or the Notification tray.

A click on the notification or claims short-link will land the user on the Claims section of the Inbox.

The user can click on any one of the mail list items under Claims section, and view the details of task.

Once the user clicks on Claim button, the request moves from the Claims section to the My Requests section. The claim user sees the success message Task claimed successfully and the user is automatically guided to the Open menu.

The user can click on the list item and view the details for access request. The approver can leave comments if needed and Accept to approve or Reject the request.

Once approved successfully, the user will see the success notification.

Connectors can be deployed in two ways:

• Local connectors are deployed to a Cymmetri instance. This is the usual way how connectors are used. The connector is executed inside a Cymmetri instance, has the same lifecycle (start/stop), etc. Cymmetri can detect local connectors automatically and overall the connector management is easier.

• Remote connectors are executed in a different process or on a different node than Cymmetri instance. Remote connectors are deployed to a connector server. There may be need to use a remote connector e.g. to access a file on a remote system (e.g. in case of CSV connector) or because of platform incompatibilities (e.g. .NET connectors)

Connector is not developed as local or remote. The placement of the connector is a deployment-time decision. There is just one connector package that can be deployed locally or remotely.

A connector server is required when a connector bundle is not directly executed within your application. By using one or more connector servers, the connector architecture thus permits your application to communicate with externally deployed bundles.

Connector servers are available for both Java and .NET.

A Java connector server is useful when you do not wish to execute a Java connector bundle in the same VM as your application. It may be beneficial to run a Java connector on a different host for performance improvements if the bundle works faster when deployed on the same host as the native managed resource. Additionally, one may wish to use a Java connector server under a Java remote connector server in order to eliminate the possibility of an application VM crash due to a fault in a JNI-based connector.

The use of .NET connector server is especially useful when an application is written in Java, but a connector bundle is written using C#. Since a Java application (e.g. J2EE application) cannot load C# classes, it is necessary to instead deploy the C# bundles under a .NET connector server. The Java application can communicate with the C# connector server over the network, and the C# connector server serves as a proxy to provide to any authenticated application access to the C# bundles deployed within the C# connector server.

Java Connector Server

Installing a Java Connector Server

Minimum Requirements:

• Java 1.6 or later for 1.4.X.Y / Java 1.8 for 1.5.X.Y

• Refer to your Java connectors to determine if there are any additional requirements

Create your execution environment

• Download the Connector Server package

• Unzip it in a directory of your choice (e.g. /usr/jconnserv) on the host where you wish to run the Java connector server

Test your execution environment

From the directory created above, run the Java connector server with no arguments to see the list of command-line options:

• Linux / MacOS: ./bin/ConnectorServer.sh

• Windows: \bin\ConnectorServer.bat

You should see the following output:

    Usage: 
           Main -run -properties 
           Main -setKey -key  -properties 
           Main -setDefaults -properties 

Configure your Java connector server

• Run the connector server with the -setKey option as described above to set your desired key into your properties file

• For all other properties (e.g. port), edit the conf/connectorserver.properties manually. The available properties are described in the connectorserver.properties file.

Running your Java connector server

Run the server by launching with the -run option:

• Linux / MacOS: ./bin/ConnectorServer.sh -run -properties conf/connectorserver.properties

• Windows: \bin\ConnectorServer.bat -run conf\connectorserver.properties

Installing Connectors on a Java Connector Server

To deploy a Java connector:

• Copy the Java connector bundle jar file into the bundles directory in your Java connector server directory

• If necessary, add to the classpath any 3rd party jars required by any Java connector

• Restart the Java connector server

Using SSL to communicate with connector servers

The following steps are necessary to successfully communicate with a connector server using SSL:

• Deploy an SSL certificate to the connector server's system.

• Configure your connector server to provide SSL sockets.

• Configure your application to communicate with the communicate with the connector server via SSL.

Configure your application to use SSL

Refer to your application manual for specific notes on how to configure connections to connector servers. You will need to indicate to your application that an SSL connection is required when establishing a connection for each SSL-enabled connector server.

Additionally, if any of the SSL certificates used by your connector servers is issued by a non-standard certificate authority, your application must be configured to respect the additional authorities. Refer to your application manual for notes regarding certificate authorities.

Java applications may solve the non-standard certificate authority issue by expecting that the following Java system properties are passed when launching the application:

• javax.net.ssl.trustStorePassword For example, -Djavax.net.ssl.trustStorePassword=changeit

• javax.net.ssl.trustStore For example, -Djavax.net.ssl.trustStore=/usr/myApp_cacerts

Or, instead, the non-standard certificate authorities may be imported to the standard ${JAVA_HOME}/lib/security/cacerts.

.NET Connector Server

Installing a .NET Connector Server

Minimum Requirements:

• Windows Server 2003 or 2008

• .NET Framework 3.5 or higher

• Refer to your .NET connector to determine if there are any additional requirements

Execute ServiceInstall.msi. Just follow the wizard. It will walk you through the whole process step by step. Upon completion, the Connector Server will be installed as a windows service.

Configuring the .NET Connector Server

Start the Microsoft Services Console. Check to see if the Connector Server is currently running. If so, stop it. From a command prompt, set the key for the connector Server. This is done by changing to the directory where the connector server was installed (by default: \Program Files\Identity Connectors\Connector Server) and executing the following command:

ConnectorServer /setkey <newkey>

where <newkey> is the value for the new key. This key is required by any client that connects to this Connector Server.

Look through the configuration file and inspect all settings. The most common things to change would be the port, trace, and ssl settings.

Additional Notes about configuration

The port, address, and SSL settings are in the tag called AppSettings, and look like this:

<add key="connectorserver.port" value="8759" />
<add key="connectorserver.usessl" value="false" />

<add key="connectorserver.certificatestorename" value="ConnectorServerSSLCertificate" />
<add key="connectorserver.ifaddress" value="0.0.0.0" />

The port can be set by changing the value of connectorserver.port. The listening socket can be bound to a particular address, or can be left as 0.0.0.0. To setup to use SSL, you must set the value of connectorserver.usessl to true, and then set the value ofconnectorserver.certifacatestorename to your the certificate store name.

You will need to record for use later the following information regarding your connector server installation:

• Host name or IP address

• Connector server port

• Connector server key

• Whether SSL is enabled

Changing Trace Settings

Trace settings are in the configuration file. The settings look like this:

<system.diagnostics>
  <trace autoflush="true" indentsize="4">
     <listeners>
       <remove name="Default" />
       <add name="myListener" type="System.Diagnostics.TextWriterTraceListener"
  initializeData="c:\connectorserver2.log" traceOutputOptions="DateTime">        
         <filter type="System.Diagnostics.EventTypeFilter" initializeData="Information" />
       </add>
    </listeners>
  </trace>
</system.diagnostics>

The Connector Server uses the the standard .NET trace mechanism. For more information about the tracing options, see Microsoft's .NET documentation for System.Diagnostics.

The default settings are a good starting point, but for less tracing, you can change the EventTypeFilter's initializeData to "Warning" or "Error". For very verbose logging you can set the value to "Verbose" or "All". The amount of logging performed has a direct effect on the performance of the Connector Servers, so be careful of the setting.

Any configuration changes will require the connector server to be stopped and restarted.

Running the .NET Connector Server

The best way to run the Connector Server is as a Windows service. When installing, the Connector Server is installed as a Windows service. This should be fine for most installations.

If for some reason, this is not adequate, the connector server may be installed or uninstalled as a Windows service by using the /install or /uninstall arguments on the command line. To run the Connector Server interactively, issue the command:

ConnectorServer /run

Installing Connectors on a .NET Connector Server

To install new connectors, change to the directory where the Connector Server was installed, and unzip the zip file containing the connector there. Restart the Connector Server.

Running Multiple Connector Servers on the Same Machine

To install additional Connector Servers on the same machine, download the Connector Server zip file from the downloads section. Create a directory to install to, and unzip the file there. Edit the configuration file as described above ensuring that you have a unique port. You may also want to make sure that the trace file is different as well. You can then run the additional Connector Server interactively or as a service.

Accessing the Applications Menu

Applications menu in the administration page displays the various options pertaining to the Application Management processes.

Applications menu may be accessed by two ways -

Identity Hub

1. Login as one of the following administrators - Organization Administrator, Domain Administrator, Application Administrator.

2. Click on the Identity Hub icon on the left side bar.

3. Click on the Applications text on the slide out bar.

Single Sign On Module

1. Login as one of the following administrators - Organization Administrator, Domain Administrator, Application Administrator.

2. Click on the Products menu icon on the left side bar.

3. Click on the Single SignOn Module icon in the popup list.

4. Click on the Applications text on the slide out bar.

Understanding the applications supported by Cymmetri

Applications supported by the Cymmetri Identity platform fall majorly into three categories -

1. Pre-configured Applications These are the applications that have already been configured by the Cymmetri Identity platform for provisioning on cloud or on-premises.

2. Custom Applications for Provisioning These are the applications that you wish to manage through Cymmetri and support the generic connectors that the Cymmetri Identity platform provides.

3. Custom Applications for Single SignOn only When you need to add an application for the purpose of performing only Single SignOn for them, Cymmetri provides the ability to add a custom application which may be configured for Single SignOn using the supported Single SignOn mechanisms.

Adding Application

Once you have chosen the application to be added from the above categories, you are ready to add a new application.

1. Click on the “Add New” button on the top-right corner in the Applications menu.

3. Now click on the tile shown in the list below to open the right slide out menu for renaming application as shown below.

4. Add your custom label (if you wish) in the text box and click on the “Add Application” button.

Conclusion

Application has been successfully added to your listing now. You may click on the configure now button to start configuring the application.

Integration with LDAP

1. For LDAP connector integration we need an LDAP server with the following detail sample.

   Host/IP

   LDAP Base Context

   service user (Manager Username)

   password (Manager User password)

3. Check policy map to add proper attributes as needed by LDAP schema.

1. Any application which supports SCIM v2.0 with bearer token is workable for application.
2. Following are configuration which is used for SCIM with bearer.

   1. Base address - It is the endpoint of the target system which supports SCIM v2 API’s.

   2. Username - Username to authenticate SCIM API endpoint.

   3. Password - Password to authenticate SCIM API endpoint.

   4. Security Token - It is a token which is used to authenticate.

   5. Grant Type - It is grant type which is used to grant access for API’s.

   6. Client Id - client id for authentication

   7. Client Secret - client secret for authentication

   8. Authentication type - It is Fixed Bearer compulsory.

   9. Update method - Patch or Put method.

   10. Accept - Http header which accepts (application/json etc).

   11. Content Type - Http header which accepts (application/json etc).

   12. Access Token Base Address - base address for access token

   13. Access Token Node Id - node id for access token

   14. Access Token Content Type - content type for access token.

Integration with Powershell

1. For the powershell connector we need a windows server machine with a connId server on it.

2. Configure powershell connector with following properties
3. Must configure powershell script with valid data using the reference below

To use this mechanism ensure that the managed application supports authentication using OpenID Connect 1.0 protocol.

OpenID Connect 1.0 is a simple authentication layer protocol built on top of OAuth 2.0 protocol. It acts as a Single SignOn mechanism and authentication mechanism for not only the Web based applications, as SAML 2.0 does, but also for applications requiring access to APIs protected by this protocol as an authorisation mechanism, and for mobile-native or Single page Applications (SPA) to verify user’s identity.

For understanding the core concepts of the OpenID Connect 1.0 protocol, it is important to grab the basics of the underlying OAuth 2.0 protocol.

Glossary of terms used in OAuth 2.0 and OpenID Connect 1.0 protocols

1. Client (RP) - Client refers to the managed application to which the end-user wishes to perform Single SignOn into. The client in the context of the OAuth 2.0 and OpenID Connect 1.0, is also referred to as the Relying Party (RP), since it relies on the Authorisation Server

   1. Client ID - Client ID is the unique identifier assigned to each managed application while configuring the application for OpenID Connect 1.0 or OAuth 2.0 flow.

   2. Client Secret - This is a secret value that is shared between the relying party and the Authorisation server, so that they may communicate and be always assured that the communication shared was actually sent by the other node in the communication.

2. Cymmetri Identity Platform - Cymmetri Identity platform in the context of OpenID Connect 1.0 Single SignOn mechanism acts as two components in the OAuth 2.0 and OpenID Connect 1.0 flows. These component roles are explained below.

   1. OpenID module (Authorisation Server) - Since the Cymmetri Identity platform acts as an Identity platform, it holds the capability to ensure that user session is valid, the user is authorised to access the managed application, among other authorisation decisions, it plays the role of Authorisation server in the OpenID Connect 1.0 process.

   2. User Management Module (Resource server) - Since the Cymmetri Identity platform acts as a user identity hub, it holds the capability to store and provide user information to a managed application for the purpose of authentication and Single SignOn, it plays the role of Resource server (Resource, being the user information) in the OpenID Connect 1.0 process.

3. User (Resource Owner) - The user information to be shared for a successful authentication is the resource in the OpenID Connect 1.0 flow, therefore, in the OAuth 2.0 terms, the user information is the resource, and the end-user is the resource owner.

4. OpenID Authorisation Endpoint - Authorization endpoint is used for accepting authentication/authorization requests in the form of redirected requests with the OpenID request query parameters added to it.

5. OpenID Token Endpoint - Token endpoint is used for generating Access and ID tokens by using the authorisation code received by the managed application (Relying Party).

6. User Information Endpoint - User information endpoint may be invoked by using the token shared to the managed application from the Cymmetri Identity platform, it will provide a list of all the user information that the user has consented to share with the end-application.

7. Token Introspection Endpoint - Token introspection endpoint is used when the relying party is an API client that requires access to the APIs protected by the OpenID Connect deployment. It will verify whether the access token is still valid and well-formed.

8. Redirect URIs - These are callback resources on the managed application, that can receive the messages sent from the Authorisation provider (Cymmetri Identity platform).

9. Scope - These are parameters used to indicate what information related to the user can be shared to the managed application.

10. State - This is a random string generated by the Relying party (managed application) to ensure that the message sent back by the Cymmetri platform is a response for the request raised by it for Single SignOn.

11. Nonce - This is a random string generated by Relying party (managed application) to ensure that the message sent back by the Cymmetri platform is a response for the request raised by it for Single SignOn and to prevent replay attacks.

12. Access Token - Access token is generated by the Cymmetri Identity platform for the purpose of authorising a client (whether an end-user OR an application using OpenID Connect). This may be verified for the purpose of ensuring the validity of the access token by the client requesting the token.

13. ID Token - The ID token is generated by the Cymmetri Identity platform for the purpose of authenticating an end-user using OpenID Connect protocol. Typically, the subject name and the email Address are shared as a part of this ID token along with any nonces or states used in the protocol are shared. This ID token may be used to get more information using the User Information Endpoint.

14. Authorisation Code - This is a string generated by the Cymmetri Identity platform for the purpose of server-to-server communication between the Relying party (managed application) and the Authorisation provider (Cymmetri Identity Platform). It may be exchanged by the relying party for the purpose of obtaining access and ID tokens.

Understanding OpenID Connect Flows

Common Use Cases for OpenID Connect 1.0

1. For performing Single SignOn with managed applications that have a backend (Typical Web Application SSO)

2. For performing Single SignOn with managed applications that do not have a backend (Single Page Applications and mobile-native applications)

3. For authorising access to REST APIs by verifying that the client making the calls has the requisite access.

Commonly Used OpenID Connect 1.0 flows

1. Authorisation Code Grant Type Flow

Typically used in the same scenario as the SAML 2.0 flow, it is used when the Identity provider and the Managed application are both capable of having a separate frontend and backend. These backends can have back-channel communication that is secure and cannot be modified or viewed in transit. This is therefore typically used when full-blown web applications are available.

2. Implicit Grant Type Flow

Typically used when the managed application is a simple Single Page application or a mobile native application that may not be able to use back-channel secure communication and a shared secret may not be used for authenticating the managed application to the Identity provider.

3. Client Credentials Type Flow

Typically used when a user is not involved and there is no need for ID tokens. The managed application handles its own authentication or is operating as a backend service only and needs to access a resource protected by the Identity provider.

Configuring and Managing OpenID Connect flow for Authorisation Code Grant Type

Understanding the Authorisation Code Grant Type

Flow Diagram

Flow Explained

1. User requests to access the application.

2. The managed application generates a random string each for state and nonce for starting the OpenID flow; and set these as the cookies for the user browser.

3. The Cymmetri Identity platform frontend will generate authorization request with the client_id, state, nonce, redirect_uri, response_type expected, and the scopes requested by the application.

4. The request will be verified by the OpenID service in the Cymmetri Identity platform backend.

5. Redirect the user to the login flow page, and initiate the login challenge-response flow.

6. Login Challenge sent by the OpenID service to the frontend.

7. Login session of the end-user is verified by the user service.

8. Once the login session is verified, the frontend service responds back to the OpenID service with the challenge sent to it, to complete the login challenge-response flow.

9. The openID service sets a login_verifier nonce as a cookie.

10. The frontend replays the authorization request to the openID service with the login_verifier nonce to initiate the consent flow.

11. The OpenID service validates the login_verifier nonce. If successful, then the OpenID service will redirect the end-user to the consent flow page.

12. The frontend would then load the consent page with the scopes expected by the managed application, as reflected in the configuration.

13. The end user must then provide the consent for the scopes to share the relevant data to the managed application.

14. The challenge-response for consent flow is sent to the OpenID service with the scopes accepted by the end-user.

15. The OpenID service will set a cookie on the user’s browser with a consent verifier nonce.

16. The frontend replays the authorization request to the openID service with the consent_verifier nonce.

17. If the response was accepted by the Consent flow, then an authorization code will be sent to the frontend.

18. The Cymmetri frontend will then redirect the user to the “redirect_uri” of the managed application with the authorization code, state, and the nonce will be sent as query parameters.

19. The managed application will verify the state and the nonce shared in step 2.

20. The managed application will then make a POST API request to the Token API of the Cymmetri OpenID service to exchange the authorization_code with the ID token and the Access token.

21. If this authorization_code is validated by the OpenID service, the managed application will receive the ID token and the Access token.

22. The managed application may simply use the ID token to get the username and email address of the user and attempt to generate a session.

23. If more user information is needed and the profile scope was consented by the user, then the managed application may make a call to the User Information endpoint of the OpenID service using the “access token” received in step 21.

24. This user information may also be used by managed application to generate a user session.

25. Once the user session is created, the managed application sets the session cookie on the user browser, and redirects the user to the managed application landing page.

Configuring the Authorisation Grant Type in the Cymmetri Identity platform

First, we need to add the managed application into the Cymmetri Identity platform deployment.

Enable the Single SignOn by -

1. Clicking on the SignOn link on the left side menu

2. Clicking the toggle button on the right side.

3. The application URL text box may be left empty OR an endpoint from the managed application may be added that can initiate the OpenID flow by making a call to the OpenID service of the Cymmetri Identity platform deployment.

Select the OpenId/OAuth radio button to start configuring OpenID flow

Click on the dropdown for Advanced Settings (OpenID)

Main Dropdown Settings

1. Client ID - Refers to the client_id to be sent to the managed application.

2. Client Name - User friendly name for the client.

3. Client Secret - Can be left blank. After saving the configuration, a popup will show the generated client secret.

4. Redirect URLs - Refers to the endpoint on the managed application, that acts as a callback URL.

Access Dropdown Settings

Scope Settings

Scopes are used to track the consents of the end-users. This is used to determine what information the end-user wishes to share with the managed application.

Let us understand the scopes in play here -

1. openid - As we wish to support OAuth 2.0 flows as well, the openid scope is optional. However, since we are dealing with OpenID Connect flow here, openid scope is mandatory for this flow.

2. email - User’s email address is shared with the managed application.

3. address - User’s address fields are shared with the managed application.

4. phone - User’s phone number and mobile number fields are shared with the managed application.

5. profile - Shares the entire list of user attributes with the managed application.

6. offline_access - <added for future-proofness, not yet implemented>

The ‘openid’ scope is mandatory for this flow.

The ‘offline_access’ scope is not currently used by the Cymmetri Identity platform deployment.

Other profiles are optional.

Providing ‘profile’ scope overrides the settings for the ‘email', ‘address’ and ‘phone’ scopes.

Grant Type setting lets the Cymmetri Identity platform know which flow you wish to opt for -

• Authorization Code refers to the current flow.

• Refresh Token has not been implemented currently for the Cymmetri Identity platform.

Since this flow requires sharing the authorization code, and NOT the ID token, we may choose “code” as a response type.

The managed application is expected to mention using query parameters while starting the OpenID Connect flow to mention which response type it is expecting from the Cymmetri Identity platform.

While, we have chosen code as our return type, we could choose any other response type that also includes code return type.

Public subject type setting is used, since it is the most common mechanism for OpenID connect flows.

Pairwise Mechanism may be supported upon request. Please contact Cymmetri Support team in case your application needs support for pairwise subject type.

This indicates the manner in which the response (access token or ID token) is shared back by the Cymmetri Identity platform to the managed application.

1. Client Secret over HTTP basic - Shared as a query parameter or a fragment to the managed application through an HTTP redirect.

2. Client Secret over HTTP POST - Shared as a part of the response body to a REST endpoint exposed by the managed application through a POST Request.

3. Private key JWT - Share JWT instead of opaque access tokens. This is no longer considered safe and other options are preferred.

No Authentication as a response type is not to be used in the OpenID Connect flow.

The current flow uses redirections to share credentials and involves user interaction. So we choose to use “Client Secret over HTTP Basic” as the response type setting for this flow.

Configuring and Managing OpenID Connect flow for Implicit Grant Type

Understanding the Implicit Grant Type

Flow Diagram

Flow Explained

1. User requests to access the application.

2. The managed application generates a random string each for state and nonce for starting the OpenID flow; and set these as the cookies for the user browser.

3. The Cymmetri Identity platform frontend will generate authorization request with the client_id, state, nonce, redirect_uri, response_type expected, and the scopes requested by the application.

4. The request will be verified by the OpenID service in the Cymmetri Identity platform backend.

5. Redirect the user to the login flow page, and initiate the login challenge-response flow.

6. Login Challenge sent by the OpenID service to the frontend.

7. Login session of the end-user is verified by the user service.

8. Once the login session is verified, the frontend service responds back to the OpenID service with the challenge sent to it, to complete the login challenge-response flow.

9. The openID service sets a login_verifier nonce as a cookie.

10. The frontend replays the authorization request to the openID service with the login_verifier nonce to initiate the consent flow.

11. The OpenID service validates the login_verifier nonce. If successful, then the OpenID service will redirect the end-user to the consent flow page.

12. The frontend would then load the consent page with the scopes expected by the managed application, as reflected in the configuration.

13. The end user must then provide the consent for the scopes to share the relevant data to the managed application.

14. The challenge-response for consent flow is sent to the OpenID service with the scopes accepted by the end-user.

15. The OpenID service will set a cookie on the user’s browser with a consent verifier nonce.

16. The frontend replays the authorization request to the openID service with the consent_verifier nonce.

17. If the response was accepted by the Consent flow, then an authorization code will be sent to the frontend.

18. The Cymmetri frontend will then redirect the user to the “redirect_uri” of the managed application with the access token, ID token, state, and the nonce will be sent as query parameters.

19. The managed application may simply use the ID token to get the username and email address of the user and attempt to generate a session.

20. If more user information is needed and the profile scope was consented by the user, then the managed application may make a call to the User Information endpoint of the OpenID service using the “access token” received in step 21.

21. This user information may also be used by managed application to generate a user session.

22. Once the user session is created, the managed application sets the session cookie on the user browser, and redirects the user to the managed application landing page.

Configuring the Implicit Grant Type in the Cymmetri Identity platform

First, we need to add the managed application into the Cymmetri Identity platform deployment.

Enable the Single SignOn by -

1. Clicking on the SignOn link on the left side menu

2. Clicking the toggle button on the right side.

3. The application URL text box may be left empty OR an endpoint from the managed application may be added that can initiate the OpenID flow by making a call to the OpenID service of the Cymmetri Identity platform deployment.

Select the OpenId/OAuth radio button to start configuring OpenID flow -

Click on the dropdown for Advanced Settings (OpenID)

Main Dropdown Settings

1. Client ID - Refers to the client_id to be sent to the managed application.

2. Client Name - User friendly name for the client.

3. Client Secret - Can be left blank. After saving the configuration, a popup will show the generated client secret.

4. Redirect URLs - Refers to the endpoint on the managed application, that acts as a callback URL.