1 of 95

Introduction to Cymmetri Cloud 2.0

FAQ

Adding the Application

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

Login as one of the following administrators - Organization Administrator, Domain Administrator, Application Administrator. []
Click on the Identity Hub icon on the left side bar.
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

Login as one of the following administrators - Organization Administrator, Domain Administrator, Application Administrator. []
Click on the Products menu icon on the left side bar.
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

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

Supported Web Browsers

Cymmetri supports the following web browsers.

Chrome

Firefox

Edge

Safari

Version of specific browsers supported by Cymmetri.

Browser

Version

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

Cymmetri Error codes

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

Error Code

Error helper text

Help

Getting Started with Cymmetri Cloud 2.0

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.

Starting your Cymmetri Cloud 2.0 Trial

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.

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.

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.

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

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

Click on the login button for proceeding with the onboarding process

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

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

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

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

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

Next Steps

Accessing Cymmetri Cloud

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

Sign In to Cymmetri

URL :

Example:

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.

First Time User Registration

All users accessing Cymmetri must pass through the first time user registration flow. The user will require the website address to access the Cymmetri cloud account, their Username and password.

URL : https://<companyname>.cymmetri.io/login

Example:

  Instructions

Below is a step-by-step guide for accessing Cymmetri and performing the first time registration flow:

Type the appropriate URL in the browser address bar.
Provide the Username in the user name prompt.

Cymmetri will provide option to login with a password

Cymmetri will require the user to change the initial password and provide a new password. If the new password provided by user does not match or does not satisfy the password policy, the user will not be able to reset the password and the Update button will not be clickable.

After the user has reset the initial password successfully, Cymmetri will ask the user to register for Multi-Factor Authentication. The system will guide the user to setup their MFA.
On clicking the Cymmetri Authenticator option, the user will be required to scan a QR code using the Cymmetri Authenticator mobile application.
Once user has successfully registered the MFA, the user will be guided to the My Workspace page.

The password for the user would be sent to the user’s registered email address. The password may also be available with Cymmetri administrative user or the user’s reporting manager.

Logging in as an end user

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.

Additionally, you might be able to follow the Forgot Password/Unlock Account flow, if your multi-factor authentication options have already been registration using the first time User registration flow.

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.

Setting up Multi-factor authentication rules for Login

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

a second factor of authentication for the password-based login process.
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.

TOTP Based - refers to the Cymmetri Authenticator option as indicated earlier in the document.
OTP Based - refers to the SMS Authenticator option as indicated earlier in the document.
Consent Based - refers to the Push Authenticator option as indicated earlier in the document.

Administration

Reports and Analytics

Report Listing

Report Scheduling

My Workspace

Getting Started

Introduction

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.

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.

How to use the My Workspace

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

Access Expiring

Running Certifications

Requests

Pending Requests
Application Requests
Claims
New Applications
New Joinees

My Access

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

Users have an option to copy and application to any tag created. Refer the copying applications to a tag below.

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.

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.

Inbox

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.

Team

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

Session Management

Application Management

FAQ

Support for Application Management

Supported Pre-configured Applications

Cloud Based Applications
1. Azure
2. Google Workplace
3. ServiceNow
4. Github (Using SCIM 2.0 connector)
On-Premises Applications
1. Active Directory
2. OpenLDAP
3. Lotus Notes

Supported Connectors

Using Cloud Connector
1. Azure
2. Google Workplace
3. ServiceNow
4. SCIM 1.1
5. SCIM 2.0 (Basic, Bearer, Fixed Bearer)
Using Locally Deployed Connector
1. Active Directory
2. Custom Script for Databases
3. LDAP
4. Lotus Notes
5. Powershell
6. REST API

Getting Started

Introduction to Application Management

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.

Adding Applications to be managed by Cymmetri

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

Login as one of the following administrators - Organization Administrator, Domain Administrator, Application Administrator.
Click on the Identity Hub icon on the left side bar.
Click on the Applications text on the slide out bar.

Single Sign On Module

Login as one of the following administrators - Organization Administrator, Domain Administrator, Application Administrator.
Click on the Products menu icon on the left side bar.
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 -

Pre-configured Applications These are the applications that have already been configured by the Cymmetri Identity platform for provisioning on cloud or on-premises.
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.
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.

Configuring Connector Server

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.

SSO How to

Configure Single Sign On

Cymmetri Single Sign On is a module that allows the end-user to simply authenticate once into the Cymmetri Identity platform web portal, and then access all the applications assigned to them without having to log in again into the target application.

The following article explains how to configure any application added to be managed in your Cymmetri Identity platform deployment to support Single SignOn mechanism.

Warning: Single SignOn Module needs to be enabled for your tenant for this configuration to be enabled and for Single SignOn to work.

Supported Single SignOn Mechanisms

Let us first visit the various supported Single SignOn Mechanisms available for the Cymmetri Identity platform.

SAML 2.0 SAML 2.0 (Security Assertion Markup Language) is a mechanism used primarily by web applications to share messages between each other to perform a Single SignOn for the end user.

OpenID Connect OpenID Connect refers to an authentication mechanism that is derived from the OpenID family of Single SignOn mechanisms. It enables the system to perform Single SignOn for a wide range of target application types (such as - Web applications, Mobile Native Applications, Desktop based Applications). It is therefore more versatile than SAML 2.0, and is more commonly used for mobile applications. It is also the mechanism used typically for social logins.

Warning: Please note that for using the above mentioned two mechanisms (SAML 2.0 and OpenID Connect), the managed application must support the corresponding mechanism.

REST API based SSO The above two Single SignOn mechanisms are based on well-accepted and standard mechanisms. However, there might be a few legacy applications in your organization, that for various reasons may not be able to integrate and support the above mentioned protocols, we have introduced Custom API-based SSO as an alternative Single SignOn Mechanism. This requires a few changes in the managed application code which will be referenced in the following section.

Note: Cymmetri Identity platform supports Custom API-based SSO mechanism. However, it is highly recommended to migrate to the aforementioned SAML 2.0 and OpenID Connect mechanisms.

Configuring Applications for Single SignOn

To allow your end-users to access applications managed by your Cymmetri Identity platform deployment, the applications must be configured for Single SignOn, and then assigned the application.

Redirect to Applications without Single SignOn

While it is not recommended for obvious reasons, as an administrator you may configure an application to be used simply for provisioning and redirection, without performing Single SignOn.

Note: The following section is to be used for configure only applications for which you do not need to perform Single SignOn. In case you need to configure any of the following Single SignOn mechanisms, you may skip this section and refer to the corresponding configuration in your chosen method of Single SignOn.

Configuring the Application URL

For configuring an application to simply redirect the enduser to the landing page of the managed application -

Once in the applications menu, click on the application tile for which you need to configure the landing page URL and then on the left side menu, select the SignOn menu item.

Toggle the “Enable Single Sign-On (SSO)” switch to open the corresponding configuration options.

Enter the landing page URL in the “Application URL” text box and click the adjoining “Save” button.

The popup indicating “SSO Updated Successfully” will indicate that the Application URL has been configured successfully for your application.

Conclusion

Assigning the application to an end user will show an application tile as shown below:

Clicking on the application tile, will redirect the user to the assigned landing page URL.

Configure SAML 2.0 Single Sign On

To use this mechanism, please ensure that your managed application supports authentication using SAML 2.0 protocol acting as the Service Provider (SP).

SAML 2.0 is a primarily web-based Single SignOn mechanism that uses XML based messages exchanged between the authenticating party, referred to as the Identity Provider (IdP) in the SAML 2.0 terms, and the relying party, referred to as the Service Provider (SP) in the SAML 2.0 terms.

In the context of Cymmetri SAML 2.0 implementation, your Cymmetri Identity platform deployment acts as the Identity provider (IdP) and the application managed that the end-user wishes to access through Single SignOn acts as the Service Provider (SP).

The mechanisms within the SAML 2.0 protocol used for sharing Single SignOn messages are referred to as the SAML 2.0 bindings. While the SAML 2.0 and its predecessor SAML 1.1 support various bindings, the Cymmetri Identity platform supports the two most commonly used bindings for web applications - viz., HTTP POST Binding and HTTP Redirect Binding. These reflect the manner in which the requests and responses are shared between the Identity provider (Cymmetri platform) and the Service Provider (managed application).

HTTP Redirect Binding - The SAML Assertion messages (request and response XML messages) are shared as GET query parameters.

HTTP POST Binding - The SAML Assertion messages (request and response XML messages) are shared as POST body messages.

Additionally, there are two flows in which SAML 2.0 Request-Response cycle may be accomplished.

Service Provider initiated flow (SP initiated flow)
Identity Provider initiated flow (IdP initiated flow)

At this stage, to start the configuration of the managed application for SAML 2.0 based SignOn mechanism, we must identify the supported flow for the managed application.

Let us explore what both of these flows mean and how to configure your managed application to use them.

Service Provider initiated flow (SP initiated flow)

Description

The SAML 2.0 Service Provider Initiated flow indicates that the Service provider (in our case, this would be the managed application to which the end-user wishes to perform Single SignOn into) has started the SAML 2.0 Single SignOn process by sending a SAML 2.0 request XML to the Cymmetri Identity platform. This is achieved by the user landing on the Single SignOn URL of the managed application.

In practice, however, since the user is typically on the Cymmetri Identity platform, we have enabled mechanisms to redirect the user to the Single SignOn URL of the managed application, when the user clicks on the application tile.

Flow Description

User lands on the SSO URL page of the managed application. (This may be either through clicking on the application tile on the Cymmetri platform or by the user actually entering the SSO URL of the managed application in the browser address bar.)
Managed application generates the SAML 2.0 request XML which holds the following important parameters - Request Id, Assertion Consumer Service URL (ACS), the protocol binding expected, and the Issuer of the request.
A redirect is made to the page handling Single SignOn requests on the Cymmetri Identity platform (<baseurl-of-cymmetri-deployment/samlsrvc/SingleSignOnService>) with the request in base64 format as a query parameter.
This page sends the SAML request body to the backend services of the Cymmetri platform to validate the request and to verify whether a session exists for a Cymmetri user in the current browser instance.
If a session does not exist for any user, the user is asked to login into the Cymmetri Identity platform.
If a session exists for the user, then the backend validates whether the user is authorised to access the application for which the SSO request has been initiated. (by checking whether the user is assigned the application.)
The backend services of the Cymmetri Identity platform generates a SAML response XML body and send it as GET request query parameter (if the protocol binding expected in the SAML request is HTTP Redirect) or as a POST request body (if the protocol binding expected in the SAML request is HTTP POST binding) to the Assertion Consumer Service URL mentioned in the SAML Request body, with the SAML Response audience as the Issuer mentioned in the SAML request body, and a field “InResponseTo” as the Request ID from the SAML request body.
The managed application would then validate the SAML response (and the signature, if was requested in the SAML request body).
If the SAML Response body is not a valid SAML Response, then the user is redirected to the managed application’s error page.
If the SAML response body is a valid SAML response, then the SAML assertion is extracted to obtain the user information sent by the Cymmetri Identity platform.
If the user information is not valid, for any reason, then the corresponding error is displayed to the user by redirecting the user to the managed application’s error page.
If all the user information is valid, the managed application initiates the user’s session in the managed application web portal, and corresponding session cookies are generated.
Finally, the user is redirected from the application’s Assertion Consumer Service URL to the landing page of the managed application.

In case of any validation errors, please refer to the section explaining the error scenarios below and change the configuration in either the managed application or the Cymmetri application SignOn configuration page.

Configuring application to use Service Provider initiated flow

The configuration parameters mentioned in the information panel below are required to configure an application for Single SignOn using the Identity provider initiated flow in the Cymmetri Identity portal.

Prerequisites from the managed Application

Request Issuer - This is the request issuer that would have been sent by the managed application in case this were a Service Provider initiated flow.
Assertion Consumer Service URL - This is the URL to which the SAML response must be sent by the Cymmetri Identity platform.
Expected NameID Policy - This indicates whether the managed application expects the user subject name to be sent as the Email Address, username, or some other unspecified value.
Expected Signature Algorithm - The expected algorithm to be used for signing the responses and assertions.

First we create an application in our Cymmetri Identity platform as discussed in previous articles. Let us use this application example below. We have already enabled SignOn as discussed here.

Let us go ahead and click on the radio button to enable SAML 2.0 option.

Let us now click on the dropdown for “Advanced Settings (SAML 2.0)”.

Click on the “Download Metadata” button, it is to be used in future steps.

Click on the purple “Download Metadata” button, it should open up a new tab with the xml file.

Let us come back to the SAML 2.0 settings for our sample managed application in Cymmetri platform deployment

Let us start entering the fields one by one.

SAML Type - We select the “SP_INITIATED” from the dropdown.

Since the metadata downloaded from the test app does not indicate the use of a particular signature algorithm, let us simply use “RSA_SHA256”.

Further, we need to select NameID Format. Referring to the highlighted portion in the metadata downloaded from the sample application, we find two supported NameID formats -

unspecified - This is a generic and default selection of NameID format, typically this would mean that the Cymmetri Identity platform may send any user attribute, which can be selected further. The managed application must handle it accordingly. This will be used whenever some custom or unusual user attribute is to be passed to the managed application.
email - This indicates to the managed application, that the Identity Provider (Cymmetri Identity Platform) will be sending the end-user’s email address, and that the managed application must handle it accordingly.

We see three other NameID formats in the dropdown, let us understand them one-by-one.

NameID Formats explained

transient - This is used as a NameID format when we wish to indicate to the managed application, that the end-user’s details sent during the SAML 2.0 process is in fact not permanent, but may change for the period of the end-user’s identity lifecycle.
persistent - This is used as a NameID format when we wish to indicate to the managed application, that the end-user’s details sent during the SAML 2.0 process is permanent, and will remain the same for the period of the end-user’s identity lifecycle.
username - This is used as a NameID format when we wish to indicate to the managed application, that we will be sharing the end-user’s username from Cymmetri Identity Provider to the managed application during the SAML 2.0 process.

Let us select email as the NameID format for now.

Let us now discuss NameID Values

There are two scenarios here -

Choosing NameID format as “username” and “email” - The value of the NameID Value will not matter, the end-user’s username or email address will be shared to the managed application.
Choosing NameID format as “unspecified”, “transient”, and “persistent” - The value of the NameID value will allow for a particular value of the User object to be shared to the managed application.

Possible Values of NameID Value are - email, mobile, firstName, lastName, displayName, loginId.

Let us select email as a NameID value, however, it will not affect the configuration.

Let us select “Exclusive” as the Canonicalization Method. Reasons may be explained here in the SAML reference document.

For configuring the “Request Issuer”, let us refer back to the downloaded saml-metadata.xml from the demo application.

We use the entityID from the downloaded metadata as the Request Issuer

Please note that the Request Issuer field is how the Cymmetri Identity platform identifies the managed application from the SAML Request sent by the managed application. Please ensure that the request issuer is unique across the deployment.

For the Assertion Consumer Service URL, we once again refer to the downloaded XML,

Let us enter the Assertion Consumer URL as “https://sptest.iamshowcase.com/acs”.

Finally, we refer to the downloaded XML one last time, for deciding upon the toggle buttons -

Here we see the managed demo application, requires only the Assertions to be signed and not the Authentication requests, we define the toggle switches accordingly.

Upload the metadata we downloaded from the Cymmetri Identity Platform configuration.

Hit the “Submit File” button to store the Identity provider metadata in the application.

Now copy the managed application’s Single SignOn URL from the popup as shown below -

Enter this URL into the SignOn configuration of the managed application on the Cymmetri Identity portal.

Click the “Save” button.

Testing the Service Provider initiated flow

Now that both sides are configured, let us test the flow by assigning the application to the current user.

Click on the “My Access” menu on the left sidebar under the “My Workspace” section.

Let us click on the application tile we created for the managed application demo.

We will now be redirected a few times and finally should land on the page below -

Identity Provider initiated flow (IdP initiated flow)

Description

The SAML 2.0 Identity Provider Initiated flow indicates that the Identity provider (in our case, this would be the Cymmetri Identity platform) has started the SAML 2.0 Single SignOn process by sending an unsolicited SAML 2.0 response XML to the Cymmetri Identity platform. This is achieved by the user clicking on the managed application tile in their workspace.

Flow Description

The user clicks on the application tile, which sends a request to the Cymmetri Identity platform backend to initiate the SAML 2.0 SignOn process.
The backend validates whether the user is authorised to access the application for which the SSO request has been initiated. (by checking whether the user is assigned the application.)
The backend services of the Cymmetri Identity platform generates a SAML response XML body and send it as GET request query parameter (if the protocol binding expected in the SAML request is HTTP Redirect) or as a POST request body (if the protocol binding expected in the SAML request is HTTP POST binding) to the Assertion Consumer Service URL mentioned in the SAML Request body, with the SAML Response audience as the Issuer mentioned in the SAML request body, and a field “InResponseTo” as the Request ID from the SAML request body.
The managed application would then validate the SAML response (and the signature, if was requested in the SAML request body).
If the SAML Response body is not a valid SAML Response, then the user is redirected to the managed application’s error page.
If the SAML response body is a valid SAML response, then the SAML assertion is extracted to obtain the user information sent by the Cymmetri Identity platform.
If the user information is not valid, for any reason, then the corresponding error is displayed to the user by redirecting the user to the managed application’s error page.
If all the user information is valid, the managed application initiates the user’s session in the managed application web portal, and corresponding session cookies are generated.
Finally, the user is redirected from the application’s Assertion Consumer Service URL to the landing page of the managed application.

Configuring application to use Identity Provider initiated flow

Prerequisites from the managed Application

Request Issuer - This is the request issuer that would have been sent by the managed application in case this were a Service Provider initiated flow.
Assertion Consumer Service URL - This is the URL to which the SAML response must be sent by the Cymmetri Identity platform.
Expected NameID Policy - This indicates whether the managed application expects the user subject name to be sent as the Email Address, username, or some other unspecified value.
Expected Signature Algorithm - The expected algorithm to be used for signing the responses and assertions.

First we create an application in our Cymmetri Identity platform as discussed in previous articles. Let us use this application example below. We have already enabled SignOn as discussed here.

Identity Provider initiated flow is a subset of the Service Provider initiated flow. Some steps are similar if you have already configured the Service Provider initiated flow.

Let us go ahead and click on the radio button to enable SAML 2.0 option.

Let us now click on the dropdown for “Advanced Settings (SAML 2.0)”.

Click on the purple “Download Metadata” button, it should open up a new tab with the xml file.

Let us come back to the SAML 2.0 settings for our sample managed application in Cymmetri platform deployment

Let us start entering the fields one by one.

SAML Type - We select the “IDP_INITIATED” from the dropdown.

Since the metadata downloaded from the test app does not indicate the use of a particular signature algorithm, let us simply use “RSA_SHA256”.

Further, we need to select NameID Format. Referring to the highlighted portion in the metadata downloaded from the sample application, we find two supported NameID formats -

unspecified - This is a generic and default selection of NameID format, typically this would mean that the Cymmetri Identity platform may send any user attribute, which can be selected further. The managed application must handle it accordingly. This will be used whenever some custom or unusual user attribute is to be passed to the managed application.
email - This indicates to the managed application, that the Identity Provider (Cymmetri Identity Platform) will be sending the end-user’s email address, and that the managed application must handle it accordingly.

We see three other NameID formats in the dropdown, let us understand them one-by-one.

NameID Formats explained

transient - This is used as a NameID format when we wish to indicate to the managed application, that the end-user’s details sent during the SAML 2.0 process is in fact not permanent, but may change for the period of the end-user’s identity lifecycle.
persistent - This is used as a NameID format when we wish to indicate to the managed application, that the end-user’s details sent during the SAML 2.0 process is permanent, and will remain the same for the period of the end-user’s identity lifecycle.
username - This is used as a NameID format when we wish to indicate to the managed application, that we will be sharing the end-user’s username from Cymmetri Identity Provider to the managed application during the SAML 2.0 process.

Let us select email as the NameID format for now.

Let us now discuss NameID Values

There are two scenarios here -

Choosing NameID format as “username” and “email” - The value of the NameID Value will not matter, the end-user’s username or email address will be shared to the managed application.
Choosing NameID format as “unspecified”, “transient”, and “persistent” - The value of the NameID value will allow for a particular value of the User object to be shared to the managed application.

Possible Values of NameID Value are - email, mobile, firstName, lastName, displayName, loginId.

Let us select email as a NameID value, however, it will not affect the configuration.

Let us select “Exclusive” as the Canonicalization Method. Reasons may be explained here in the SAML reference document.

For configuring the “Request Issuer”, let us refer back to the downloaded saml-metadata.xml from the demo application.

We use the entityID from the downloaded metadata as the Request Issuer

For the Assertion Consumer Service URL, we once again refer to the downloaded XML,

Let us enter the Assertion Consumer URL as “https://sptest.iamshowcase.com/acs”.

Finally, we refer to the downloaded XML one last time, for deciding upon the toggle buttons -

Here we see the managed demo application, requires only the Assertions to be signed and not the Authentication requests, we define the toggle switches accordingly.

Click on the “Save” button.

Testing the Identity Provider initiated flow

Now that both sides are configured, let us test the flow by assigning the application to the current user.

Click on the “My Access” menu on the left sidebar under the “My Workspace” section.

Let us click on the application tile we created for the managed application demo.

We will now be redirected a few times and finally should land on the page below -

Possible Error Scenarios in Validation

Scenario 1: SAML request body does not meet the validation requirements for the SAML request.

Cause: Incorrect implementation of the SAML protocol by the managed application.

Fix: Verify that the SAML protocol is accurately implemented by the managed application.

Scenario 2: SAML request body does not have the same issuer as the configuration in the Cymmetri platform.

Cause: Incorrect configuration of SignOn on the Cymmetri platform for the managed application.

Fix: Change the request Issuer in the managed application configuration on the Cymmetri platform according to the Issuer field in the SAML request.

Scenario 3: SAML response body does not meet the validation requirements for the SAML response.

Cause: Incompatible expectations of the SAML 2.0 response body between the managed application and the Cymmetri Identity platform.

Fix: Connect with the Cymmetri Identity platform support team.

Scenario 4: SAML Response assertion has the incorrect audience.

Cause: Incorrect configuration of the request issuer field in the Cymmetri Identity platform for the managed application.

Fix: Verify and change the request issuer field in the managed application configuration on the Cymmetri platform according to the Issuer field in the SAML request.

Scenario 5a: User from the SAML Assertion is not valid.

Cause: Incorrect name ID format.

Fix: Verify and change the NameID format as expected by the managed application.

Scenario 5b: User from the SAML Assertion is not valid.

Cause: Incorrect user field in the assertion.

Fix: Verify that the right user field is selected as the “NameID Value” in the managed application configuration and Verify that the user information has the correct information as expected by the managed application in the field selected as the “NameID Value” in the managed application configuration on the Cymmetri platform.

Scenario 5c: User from the SAML Assertion is not valid.

Cause: User information is as expected but scenario 5b is not the cause.

Fix: Verify that the user information is present in the user database of the managed application. In case the managed application has JIT feature, ensure that the SAML attributes are correctly configured.

Configure SAML attributes

In case of default attributes, the user object already has the attributes, we just need to ensure that the right values are assigned to these attributes. In case of custom attributes, custom attributes must be added to your Cymmetri Identity platform deployment.

Let us investigate how this works out in the SAML 2.0 process and how the data is received from the Cymmetri Identity platform.

Let us click on the “configure SAML attributes” link in the configuration page

On clicking the following should pop up

Let us add an attribute mapper as per the table defined above

We have added the First Name of the user from the Cymmetri Identity Platform to the managed Application as the key “First Name”.

Click on the save icon next to the delete icon (trash can icon).

Click on the “X” icon to close the attribute mapper.

Now once again go back to the “My Access” page and click the application tile.

Once we obtain the results after the redirections we should find the attributes sent to the managed application.

As is visible, the SAML response now holds the attributes as “First Name” and the “Last Name”.

Samples

SAML 2.0 Sample Request

SAML 2.0 Sample Response

Configure API SSO

Cymmetri platform highly recommends adding support to either SAML 2.0 or OpenID Connect protocols owing to their well-accepted standards and to avoid vendor lock-in.

In the absence of the ability of the managed application to adopt either the SAML 2.0 or the OpenID Connect 1.0 standard, the Cymmetri Identity platform provides with the ability to integrate simple REST API based mechanism to allow an end-user to perform Single SignOn from the Cymmetri Identity Portal

REST API based SSO Explained

Flow explained

User is assigned the application and clicks on the application tile.
The end user session is captured as the client IP address as received from the user’s browser.
The user session is validated and the Cymmetri Identity platform checks if the end user is authorised to perform Single SignOn into the managed application.
In case, such a session token is created and the end-user is redirected as a query parameter to an endpoint on the managed application.
The endpoint on the managed application also captures the end-user’s client IP address, and sends the received token to its backend.
The managed application backend already holds the Application ID and Application password assigned to it when the API-based SSO is configured on the Cymmetri Identity platform.
The managed application backend now makes a POST call to the validate token API endpoint exposed by the Cymmetri Identity platform with the form parameters as follows -
1. app_id - Previously shared application ID
2. app_pass - Previously shared application password
3. user_ip - End-user’s client IP address as captured from the end-user’s browser
4. auth_token - the token sent to the endpoint of the managed application.
The Cymmetri Identity platform responds back with a success message in case the application ID, application Password, client IP address and the user session string match with the corresponding records in its backend.
In case of success, the managed application is expected to generate a user session for the prescribed user Id as shared in the success response message.
The Cymmetri Identity platform responds back with a failure message in case of even one parameter mismatch from among - application ID, application Password, client IP address or the user session string (shared token).
In case of failure, the managed application is expected to cancel the login attempt and show the error message shared by the Cymmetri Identity platform.

Configuration for REST API based SSO mechanism

For configuring the REST API based SSO mechanism, first select the application already added into your Cymmetri Identity platform deployment.

Then proceed to the SSO configuration using the “SignOn” link in the left-hand side menu bar.

Enable the Single SignOn by clicking the toggle button on the right-hand side of the page.

Now enter the application URL as below -

Application URL = <base url of the deployment>/apiSSO?applicationId=<applicationId>

Let us first copy the URL from the address bar -

The corresponding URL in my case is -

https://ssotester.cymmetri.io/application/6241c3b604c15417a91c7030/sign-on

We evaluate the following values from the URL -

Base URL of the deployment - https://ssotester.cymmetri.io
applicationId - 6241c3b604c15417a91c7030

Now we generate the Application URL as - https://ssotester.cymmetri.io/apiSSO?applicationId=6241c3b604c15417a91c7030

Let us enter this value in the Application URL text bar and click the “Save” button.

Let us proceed by selecting the radio button “API-based SSO”

Click on the dropdown “Advanced Settings (API)” to configure the API-based SSO and enter the information -

Configuration Parameters

Source app token param name - Refers to the key of the query parameter used to share the randomly generated token from the Cymmetri backend.
Application Secret - Refers to the parameter app_pass that must be sent back by the managed application to validate the token.
Target App Redirect URL - Refers to the endpoint exposed by the managed application to receive the token as a query parameter.
Token Validity - number of seconds for which the generated token is valid. The managed application must send back the token for validation within these many seconds.
Target app token param name - This is the field that the managed application must use to send back the token for validation.
External Application ID - Refers to the parameter app_id that must be sent back by the managed application to validate the token.

Assign the application to a user.

On clicking the application tile, the user is redirected to the URL below as per the configuration above.

http://localhost:4124/getToken?auth_token=<random token>

Once the token is received by the application, the application makes a POST call as indicated by the CURL request below -

curl --location --request POST 'https://ssotester.cymmetri.io/api-sso/api/sso/validateToken' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'app_id=demoapps' \ --data-urlencode 'app_pass=Pras@4i1m$' \ --data-urlencode 'auth_token=<random token>' \ --data-urlencode 'user_ip=<client IP address>'

Responses from the Validation

Success Response

JSON response

{

“status”:”Success”,

“allow_user”:”true”,

“user_id”:”abhishek.kulkarni”

}

Error Response

JSON Response

{

“status”:”User not verified”,

“allow_user”:”false”,

“user_id”:”abhishek.kulkarni”

}

In case of this error, “User not verified” message must be shown by the managed application. The user must not be allowed to login.

JSON Response

{

“status”:”Application not verified”,

“allow_user”:”false”,

“user_id”:”abhishek.kulkarni”

}

In case of this error, “Application not verified” message must be shown by the managed application. The user must not be allowed to login. The application configuration on the Cymmetri Identity platform and the managed application must be validation and cross-verified.

Configure OpenID Connect based Single SignOn

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

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.
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.
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.
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.
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).
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.
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.
Redirect URIs - These are callback resources on the managed application, that can receive the messages sent from the Authorisation provider (Cymmetri Identity platform).
Scope - These are parameters used to indicate what information related to the user can be shared to the managed application.
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.
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.
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.
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.
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

For performing Single SignOn with managed applications that have a backend (Typical Web Application SSO)
For performing Single SignOn with managed applications that do not have a backend (Single Page Applications and mobile-native applications)
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

User requests to access the application.
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.
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.
The request will be verified by the OpenID service in the Cymmetri Identity platform backend.
Redirect the user to the login flow page, and initiate the login challenge-response flow.
Login Challenge sent by the OpenID service to the frontend.
Login session of the end-user is verified by the user service.
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.
The openID service sets a login_verifier nonce as a cookie.
The frontend replays the authorization request to the openID service with the login_verifier nonce to initiate the consent flow.
The OpenID service validates the login_verifier nonce. If successful, then the OpenID service will redirect the end-user to the consent flow page.
The frontend would then load the consent page with the scopes expected by the managed application, as reflected in the configuration.
The end user must then provide the consent for the scopes to share the relevant data to the managed application.
The challenge-response for consent flow is sent to the OpenID service with the scopes accepted by the end-user.
The OpenID service will set a cookie on the user’s browser with a consent verifier nonce.
The frontend replays the authorization request to the openID service with the consent_verifier nonce.
If the response was accepted by the Consent flow, then an authorization code will be sent to the frontend.
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.
The managed application will verify the state and the nonce shared in step 2.
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.
If this authorization_code is validated by the OpenID service, the managed application will receive the ID token and the Access token.
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.
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.
This user information may also be used by managed application to generate a user session.
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 -

Clicking on the SignOn link on the left side menu
Clicking the toggle button on the right side.
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

Client ID - Refers to the client_id to be sent to the managed application.
Client Name - User friendly name for the client.
Client Secret - Can be left blank. After saving the configuration, a popup will show the generated client secret.
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 -

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.
email - User’s email address is shared with the managed application.
address - User’s address fields are shared with the managed application.
phone - User’s phone number and mobile number fields are shared with the managed application.
profile - Shares the entire list of user attributes with the managed application.
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.

Client Secret over HTTP basic - Shared as a query parameter or a fragment to the managed application through an HTTP redirect.
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.
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

User requests to access the application.
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.
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.
The request will be verified by the OpenID service in the Cymmetri Identity platform backend.
Redirect the user to the login flow page, and initiate the login challenge-response flow.
Login Challenge sent by the OpenID service to the frontend.
Login session of the end-user is verified by the user service.
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.
The openID service sets a login_verifier nonce as a cookie.
The frontend replays the authorization request to the openID service with the login_verifier nonce to initiate the consent flow.
The OpenID service validates the login_verifier nonce. If successful, then the OpenID service will redirect the end-user to the consent flow page.
The frontend would then load the consent page with the scopes expected by the managed application, as reflected in the configuration.
The end user must then provide the consent for the scopes to share the relevant data to the managed application.
The challenge-response for consent flow is sent to the OpenID service with the scopes accepted by the end-user.
The OpenID service will set a cookie on the user’s browser with a consent verifier nonce.
The frontend replays the authorization request to the openID service with the consent_verifier nonce.
If the response was accepted by the Consent flow, then an authorization code will be sent to the frontend.
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.
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.
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.
This user information may also be used by managed application to generate a user session.
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 -

Clicking on the SignOn link on the left side menu
Clicking the toggle button on the right side.
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

Client ID - Refers to the client_id to be sent to the managed application.
Client Name - User friendly name for the client.
Client Secret - Can be left blank. After saving the configuration, a popup will show the generated client secret.
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 -

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.
email - User’s email address is shared with the managed application.
address - User’s address fields are shared with the managed application.
phone - User’s phone number and mobile number fields are shared with the managed application.
profile - Shares the entire list of user attributes with the managed application.
offline_access - <added for future-proofness, not yet implemented>

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

Implicit refers to the current flow.

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

Since this flow requires sharing the ID token directly along with access token, we may choose “id_token” or “id_token token” 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 'id_token token' as our return type, we could choose any other response type that also includes both of these return types.

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.

Credential Dropdown Settings

Client Secret over HTTP basic - Shared as a query parameter or a fragment to the managed application through an HTTP redirect.
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.
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 Client Credentials Grant Type

Understanding the Client Credentials Grant Type

Flow Diagram

Flow Explained

Generating Access Token for the Managed Application

OpenID service shares client ID, client secret, and audience to the managed application during the configuration phase.
The managed application makes a POST request to the token API of the OpenID service with the previously shared clientID, client secret, the audience string, and the grant_type as “client_credentials”.
The OpenID service validates the combination of (client_id, client_secret, and audience) and generates an access token to be shared to the managed application with an expiry time (in seconds).
The managed application should then verify the access token received by calling the token introspection endpoint.

Using the Access token to access protected API resource

The managed application should first request an access token as discussed above.
The managed application may then attempt to access the protected resource by sharing the client_id and authenticate the request using Bearer token as the access_token.
The protected resource may then validate the access token shared by calling the token introspection and validate that the client_id shared by the managed application in step 2 matches the client_id for which the access_token was generated, and that the token has not expired.
If the validation in step 3 is successful, the protected resource will be shared to the managed application.

Configuring the Client Credentials 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 -

Clicking on the SignOn link on the left side menu
Clicking the toggle button on the right side.
The application URL text box may be left empty for this flow, since the user does not need to be involved with this flow.

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

Click on the dropdown for Advanced Settings (OpenID)

Main Dropdown Settings

Client ID - Refers to the client_id to be sent to the managed application.
Client Name - User friendly name for the client.
Client Secret - Can be left blank. After saving the configuration, a popup will show the generated client secret.
Redirect URLs - Refers to the endpoint on the managed application, that acts as a callback URL.
Audience - This audience needs to be shared by the managed application, and the Cymmetri Identity platform will validate it for providing access token.

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 -

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.
email - User’s email address is shared with the managed application.
address - User’s address fields are shared with the managed application.
phone - User’s phone number and mobile number fields are shared with the managed application.
profile - Shares the entire list of user attributes with the managed application.
offline_access - <added for future-proofness, not yet implemented>

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 access token, 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.

Credential Dropdown Settings

Client Secret over HTTP basic - Shared as a query parameter or a fragment to the managed application through an HTTP redirect.
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.
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 has API exchange of tokens and validations. So we choose to use “Client Secret over HTTP POST” as the response type setting for this flow.

Provisioning How to

Azure Provisioning

Cymmetri Identity Platform application catalogue allows for pre-configured provisioning settings for Azure Portal.

For Azure integration we need an azure enterprise account with its own domain configured in the Azure AD.

Refer following document to configure azure application
Azure Document https://connid.atlassian.net/wiki/spaces/BASE/pages/308674561/Azure [ConnID]
Create a new OAuth2 Application and provide the following configuration in Azure OAuth2 application.
Application will be created and now we will be able to configure.
Let us now click on Authentication tab on the left-hand side menu. We can choose account either in a single Organization Directory or multiple directory.
Click on Add a platform and we can add a new Redirect URI as “http://localhost”.
Further we can allow the Public Client flows.
Create a new Secret by first, clicking on Certificate and Secrets on the left-hand side menu, and then click on the “+ New Client secret” link, Enter Description and select the Expires option.
Provide the right permissions for the Connector to work by clicking on API Permissions tab on the left-hand side menu, then click on Add, then click on Microsoft Graph and then click on Application Permission and Delegated.
Search and select the following permissions/scopes in OpenID
1. APIConnectors.Read.All
2. Directory.ReadWrite.All
3. OpenID
4. PrivilegedAccess.Read.AzureAD
5. User.ReadWrite.All
We need to take consent from admin for getting access to Microsoft Graph API, Click on add permission, Click on “Grant Admin content for Unotech Software”, and finally Click on Yes.
Click on Expose an API and Click on Set to expose the API to be used by the Azure API client on the connector.

Configuration on Cymmetri Identity Platform for Azure provisioning

Configure the User Configurations
1. Copy the application authority from the User Configure.
2. Configure the Client ID.
3. Configure the Client Secret.
5. Configure the Redirect URI exposed from the Azure AD.
6. Graph API base endpoint (User Config Resource URI)
7. Add the Azure Tenant ID
8. Choose the base username.

Click on Save, and test the connection.

Active Directory (AD) Provisioning

Configuration on Cymmetri Identity Platform for Active Directory

For active directory configuration we need AD server with 636 port (ldaps protocol should be enabled).

Test AD configuration before assigning an application to any user.

After testing AD configuration, Active Directory account will created for the user being provisioned into the Active Directory.

The Cymmetri Identity platform Active Directory provisioning supports the following functions -
1. Create user
2. Update user
3. Delete user

Server hostname needs to be configured for public access

LDAP Provisioning

Integration with LDAP

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)
After configure LDAP server we need to configure the Ldap application into the Cymmetri.
Check policy map to add proper attributes as needed by LDAP schema.

Powershell Provisioning

Integration with Powershell

For the powershell connector we need a windows server machine with a connId server on it.
Configure powershell connector with following properties
Must configure powershell script with valid data using the reference below

Reference: https://drive.google.com/drive/folders/1XHt6aNmPzs7V7OKesk31FwqLxGf3u2ST?usp=sharing

REST Connector Provisioning

Integration REST Application

The REST connector is designed to manage provisioning by relying on RESTful service.
For REST applications we need target applications which support REST API’s.
Following configuration is tested for felicity application.
We need REST API’s to integrate with cymmetri.
Following are the cymmetri configuration which need to configure in user configuration in cymmetri.
It is Basic REST configuration which need to configure in application.

We need to provide Groovy code to run create user, update user, delete user and also recon pull and push (for recon pull we need to add sync script and for recon push we need to add search script)
For sample script please validate following link

https://drive.google.com/drive/folders/1Vs8y1ZHXV3AjqsPkQSnwUoVppL-yc8Vl?usp=sharing

Note: Please Configure script step by step

Configure test script at initial step and then test configuration for provided script (If configure successfully then only go for step b).
Configure create script and test configuration (If successfully configured then only go for step c).
Configure update script and test configuration (If successfully configured then only go for step d).
Configure delete script and test configuration (If successfully configured then only go for step e).
Configure sync(pull) script and test configuration (If successfully configured then only go for step f).
Configure search(push) script and test configuration (If successfully configured then only go to the next step).

SCIM v2.0 Provisioning with Basic Authentication

Integration SCIM v2.0 with Basic

Any application which supports SCIM v2.0 with basic authentication is workable for application.
Following are configuration which is used for SCIM with basic authenticator.

Base address - It is the endpoint of the target system which supports SCIM v2 API’s.
Username - Username to authenticate SCIM API endpoint.
Password - Password to authenticate SCIM API endpoint.
Authentication type - It is Fixed Bearer compulsory.
Update method - Patch or Put method.
Accept - Http header which accepts (application/json etc).
Content Type - Http header which accepts (application/json etc).

SCIM 2.0 with Bearer Authentication

Any application which supports SCIM v2.0 with bearer token is workable for application.
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.

Github Provisioning

Github Enterprise provides provisioning using SCIM 2.0

Pre-requisites

Create an account in Github (Enterprise).
Enable SAML for the Github tenant to be used with Cymmetri.

Step 1. Configure SSO in Cymmetri

Note the application URL received from the Git SAML configuration

Continue the configuration by logging into Cymmetri using at least Application Administrator role

Note: Public certificate gets from SSO metadata(cymmetri) and format it using following

Note: Make sure when you test SAML then in cymmetri login with github admin users loginid which is added in cymmetri.

Configure Profile Mapping

Create User in Cymmetri and make sure login id of Cymmetri is same as gitHub Admin user login id.

Test SSO with the Cymmetri user.

Configure SCIM v2.0 (Github) application from master (cymmetri).
Basic provisioning policy attribute and policy map already aaded in default schema.
Github Application is run using Fixed Bearer token.
To get Fixed bearer token following steps used.

Step 1: Go to user settings in github

Step 2: Go to developer settings

Step 3: Go to personal access token and generate new token

Step4: Click on Configure SSO

Step 5: Click on Authorize

Use following cymmetri provision configuration and change according to github account.
Fixed Bearer Value copy from personal access token
Click on save
Click on Test Configuration with success message.
Check Policy map
Disable default for the respective attribute

Reconciliation How to

Configuring Reconciliation Process

Once the applications have been configured to allow that the end-users have been provisioned into the managed application. We may now start configuring the reconciliation process for an application. The reconciliation process involves identifying the user attributes as stored in the Identity hub (Cymmetri Identity platform deployment) and their attributes as a user or a group account in the managed application; and the ensuring that the synchronization of the user and group accounts takes place either one-way or both ways between the managed application and the Identity hub, to ensure that there no discrepancies in the accounts stored by both the systems.

The reconciliation process may follow two strategies -

Full Reconciliation Full reconciliation is typically carried out when the managed application is first introduced into an organization’s Cymmetri Identity platform deployment. This involves ensuring all user (and group accounts, where applicable) account from the Cymmetri Identity platform, are synchronized with the account information on the managed application. This often takes a longer time, and is often only used as a one-time activity.
Filtered Reconciliation The Cymmetri identity platform and the managed application might lose synchronization due to a number of reasons, including backend changes to the user or group account information on the managed application or failure of communication between the identity platform and the managed application. In such cases, filtered reconciliation is employed on a regular, scheduled basis. This includes filters for a particular set of users, or to choose only the users that have been modified on either platforms, this is known as filtered reconciliation.

Cymmetri Identity platform allows for both types of reconciliation phases, by allowing administrator to define an optional user filter during the reconciliation process.

The reconciliation process involves two major processes -

Pull In this mechanism, the Cymmetri Identity platform allows for user and group account information to be pulled from the managed application.
Push In this mechanism, the Cymmetri Identity platform pushes the user and group account information to be pushed to the managed application.

Regardless of the process employed, the configuration for the most part remains the same. Let us explore the reconciliation configurations on the Cymmetri Identity Platform -

You may access the reconciliation menu by clicking on the application tile, and then clicking on the “Reconciliation” left-hand side menu bar.

Proceed to configure by clicking on the “+ Add New” button.

Name - Refers to the name of the Reconciliation process
Modes - FILTERED_RECONCILIATION (Currently the only mode supported by Cymmetri)
Sync Fields - The field from the user/group’s account information as available on the Cymmetri Identity platform that must be used as a basis to identify the corresponding account on the managed application database.
Source Attributes - The field from the user/group’s account information as available on the managed application database that must be used as a basis to match with the “Sync fields”.
Status - Whether to run the reconciliation for Active/Inactive users.
Type - Some applications allow GROUP reconciliation, but most will have USER reconciliation only.

Filled Reconciliation basic configuration looks as above.

Conditions indicate what happens when any of the following scenarios occur -

Let us assume we are synchronizing the Cymmetri Identity Platform with a cloud provider using email or mail attribute as the Sync field. As such users on both platforms having the same email address will be matched/un-matched.

Following are the scenarios managed by the Cymmetri platform -

User does not exist in Target system & exists in Cymmetri This indicates a situation during a pull phase or a push phase, where the user account exists on the Cymmetri platform, but not in the managed application. This typically occurs when the users have been pulled into the Cymmetri platform, but the managed application is yet to be synchronized with these users.
User exists in Cymmetri & Target system This indicates a situation during a pull phase or a push phase, where the user account exists on the Cymmetri platform and in the managed application, but they may or may not have the same attributes or the same values of the attributes.
User exists in Target system & does not exist in Cymmetri This indicates a situation during a pull phase or a push phase, where the user account exists in the managed application database but not on the Cymmetri Identity platform. This typically occurs when the users have been pulled into the managed application through its backend and the users have not been centrally managed through the Cymmetri platform.

Conditions explained

User does not exist in Target system & exists in Cymmetri
1. PROVISION - User is created in the target system with the attributes as present in their Cymmetri user profile.
2. IGNORE - User is not modified in either system.
3. UPDATE - Not relevant for this scenario.
4. DEPROVISION - User is removed from the Cymmetri Identity platform to be consistent with the managed application user database.
5. UNASSIGN - Not relevant for this scenario.
6. ASSIGN - User is assigned access to this system in Cymmetri, this option may be used in the case of options like JIT being available to generate user profile in the managed application.
7. UNLINK - Not relevant for this scenario.
8. LINK - Not relevant for this scenario.
User exists in Cymmetri & Target system
1. PROVISION - User is created in the target system with the attributes as present in their Cymmetri user profile.
2. IGNORE - User is not modified in either system.
3. UPDATE - User information from the Cymmetri Identity platform is updated using the account information from the managed application and vice versa.
4. DEPROVISION - Not relevant for this scenario.
5. UNASSIGN - Not relevant for this scenario.
6. ASSIGN - User is assigned the managed application on the Cymmetri platform in case they are already not assigned.
7. UNLINK - Not relevant for this scenario.
8. LINK - Not relevant for this scenario.
User exists in Target system & does not exist in Cymmetri
1. PROVISION - User is created in the Cymmetri Identity platform deployment using the account information from the managed application.
2. IGNORE - User is not modified in either system.
3. UPDATE - Not relevant for this scenario.
4. DEPROVISION - User is removed from the managed application user database.
5. UNASSIGN - Not relevant for this scenario.
6. ASSIGN - Not relevant for this scenario.
7. UNLINK - Not relevant for this scenario.
8. LINK - Not relevant for this scenario.

Scheduling the reconciliation Process

Next Execution Date This indicates the base date to start the execution date and time of the reconciliation process.
Cron Expression This indicates the frequency with which the further reconciliation events will be run. There are 6 fields here - * * * * * * (e.g., 5 15 0 1 8 *) ; they refer to seconds, minutes, hours, days, months, and year after the first execution date.

Managing Users and Groups

Setting up Users and Groups

Create Users

While users may be imported and sychronized from other Identity providers, sometimes users may need to be added manually by the administrator.

Steps to create users

First navigate to the User configuration page, by clicking on the Identity hub > User menu on the left-hand side panel.
Click on the blue “+Add New” button.
Enter the required information and scroll down to add further information
Click on the save button to move to the next configuration page, and copy the automatically generated password.
(Optional) Assign a group to the user.
(Option) Assign applications to the user.

The user has now been created with the assigned groups and assigned applications.

Create Groups

Administrator tasks pertaining to bulk users may be eased by creating groups of users.

Creating User Groups

Access the group configuration page by clicking the Identity Hub menu on the left-hand side, and then clicking on the groups in the pop-up menu.

Click on the “+Add New” button to start creating a new group

Group Name - Indicates the name of the group.

Group Type - For environments not using Active Directory, either Local or Remote Group may be chosen, in case Active Directory is being used for synchronization in the tenant, the appropriate type according to the group policy object must be chosen.

Parent Group - If a parent group is chosen, all the policies and rules applicable to the parent group will be assigned to this new group, in addition to the policies and rules specifically applied to this new group.

Group Description - Optionally, a description may be provided to the group.

Importing Users

Users may be imported into the Cymmetri Identity Portal using the bulk import users option.

Importing Users

Administrator may go to the Identity Hub left hand side menu, then select users. Then click on the Import Users button on the right hand corner.

Upload the csv file, you may use the sample data file and modify it to match your user details.

Match the Column names from the CSV file with the Cymmetri User Attributes using this user import dialog box.

Scroll down and click the save button.

The results of the import and the reasons for failures if any will be shown as well.

Assigning Users to Groups

Assigning Users to a Group

Users once created in the Cymmetri Identity platform can be assigned to a group. Assigning users to a group helps ease the administrative efforts to apply the same policies and assigning applications to multiple users.

Adding User to Group

1. First the administrator needs to click on the group name and enter the configuration for the group.

2. Now click on +Add Users button to add users to the group

3. Now click on the assign button next to the user you wish to add to the group.

Setting up permissions for Delegation

Delegation as a process in the Cymmetri Identity platform refers to the ability of any end-user to delegate their responsibilities to one or more end-users on the platform for whom they are marked as the reporting manager.

As such, delegation provides the ability to the delegatee to perform various actions, including Single Sign On, Application Requests, managing workflows by providing approvals, performing Cymmetri administrative actions (if the delegator has the required permissions on the platform), among other actions. However, the login flow for the delegatee stays the same. Configuring the delegation on your tenant

Access the Delegation administration panel, by clicking on the Configuration left-hand side menu item and then click on the Delegations pop-up menu item.
Add Users who can delegate their activities by clicking on the Assign New button.
Personalize the messages to be displayed when consent is invoked

The user consent will be displayed whenever the delegator (user) will go to their settings in their Workspace and assign a delegation to an end-user (assignee) for whom they are a manager. This consent will be recorded in the Cymmetri backend for audit logging purpose. Similarly, the assignee consent will be recorded when the end-user (delegate/assignee) logs into the account for their manager (delegator/user).

Common Features

Features used throughout the Cymmetri Platform

Personalization

How to configure your tenant and personalize it

Authentication

Identity Federation

Governance

Access Certification

Additional Tools

Miscellanous Tools and Utilities

Privileged Access Management

PAM Administration

Configuring Webhooks

Webhooks are a way for external systems to receive events from the Cymmetri Identity Platform.

Requires the tenant organization to run a web server that is exposed to the Internet or at least accessible from the Cymmetri Cloud 2.0 deployment on the cloud

Events may be received for the following events -

Testing Webhook - Generates a POST request to the /test endpoint of the web server hosted by the tenant. It provides an authorization token that can be used for making any API calls to the Cymmetri Cloud 2.0 APIs. Is generated after this configuration. Go to the Configuration Menu and Select the webhooks menu -
Click on the save & test button.
Pre Create User - Generates a POST request, before the user is created, to the /preCreateUser endpoint of the web server hosted by the tenant.
Pre Update User - Generates a POST request, before the user is updated, to the /preUpdateUser endpoint of the web server hosted by the tenant.
Post Update User - Generates a POST request, after the user is updated, to the /postUpdateUser endpoint of the web server hosted by the tenant.
Validate User - Generates a POST request, before the user is created and validation is to be run, to the /validateUser endpoint of the web server hosted by the tenant.
Validate Update User - Generates a POST request, before the user is created and validation is to be run, to the /validateUpdateUser endpoint of the web server hosted by the tenant.
Change password - Generates a POST request, upon the change of password for a user, to the /changePassword endpoint of the web server hosted by the tenant.
Pre Provision - Generates a POST request, before the provisioning of the user to an application, to the /preProvision endpoint of the web server hosted by the tenant.
Post Provision - Generates a POST request, after the provisioning of the user to an application, to the /postProvision endpoint of the web server hosted by the tenant.
Policy Map - Generates a POST request, while assigning the application to a user, to the /policyMap endpoint of the web server hosted by the tenant.
Deprovision Run - Generates a POST request, upon the update of a user to deprovision a user, to the /runDeprovision endpoint of the web server hosted by the tenant.

While other webhooks operate on a principle of fire-and-forget, the validateUser and the validateUpdateUser expect the response from the tenant as the same or modified body as sent to it for validation.

API body for the endpoints

Test web hook

Purpose : This api is used to test web hook api.

Input Needed: NA

Curl Request:

curl --location --request POST 'http://192.168.29.227:8080/webhook/test' \

--header 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhZG1pbiIsImRlbGVnYXRlZSI6bnVsbCwiZGVsZWdhdGVlSWQiOm51bGwsImZpcnN0TG9naW4iOmZhbHNlLCJyb2xlcyI6WyJPUkdfQURNSU4iLCJVU0VSIl0sInRlbmFudElkIjoiYXMxMDAiLCJleHAiOjE2NDYzOTYzMDgsInVzZXJJZCI6IjYyMTRkYjdiZDY2MWE1NzM4NmE3MWYxMCIsImlhdCI6MTY0NjM5MDMwOH0.bdKZ3UBCedT91bJAWLCo2AOahIs5ClFMAhnj36f_ecQ' \

--header 'Content-Type: application/json' \

--data-raw '{

Response:

{ "response": {} }

Pre Create User

Purpose : This web hook api is used to do some events before creating a user in the target system.

Input needed :

{

"request": {

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Curl request:

curl --location --request POST 'https://52.66.206.31:8080/webhook/preCreateUser' \

--header 'Content-Type: application/json' \

--data-raw '{

"request": {

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Response: {

"response": {

"data": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Post create User

Purpose : This web hook is used to do some events after creating a user in the target system.

Curl request: curl --location --request POST 'http://192.168.1.193:8080/webhook/postCreateUser' \

--header 'Content-Type: application/json' \

--data-raw '{

"request": {

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Response : NA

Restful API - Pre update user

Purpose : This web hook is used to do some events before updating a user in the target system.

Input needed:

{

"request": {

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Curl request:

curl --location --request POST 'http://192.168.1.193:8080/webhook/preUpdateUser' \

--header 'Content-Type: application/json' \

--data-raw '{

"request": {

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Response

{

"response": {

"data": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Post update user

Purpose : This web hook is used to do some events after updating a user in the target system.

Input needed :

{

"request": {

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Curl request:

curl --location --request POST 'http://192.168.1.193:8080/webhook/postUpdateUser' \

--header 'Content-Type: application/json' \

--data-raw '{

"request": {

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Response: NA

Validate User

Purpose : This web hook is used to validate users before creating a user in the target system.

Input Needed :

{

"request": {

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Curl request: curl --location --request POST 'http://192.168.1.193:8080/webhook/validateUser' \

--header 'Content-Type: application/json' \

--data-raw '{

"request": {

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Response: {

"response": {

"error": true,

"message": "MobileAlreadyExist"

}

Validate update user

Purpose : This web hook is used to validate users before updating a user in the target system.

Input needed:

"request": {

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Curl request:

curl --location --request POST 'http://192.168.1.193:8080/webhook/validateUpdateUser' \

--header 'Content-Type: application/json' \

--data-raw '{

"request": {

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Response:

{

"response": {

"error": true,

"message": "EmailAlreadyExist"

}

Change password

Purpose : This web hook is used to do some events on password change.

Input Needed :

{

"request": {

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

"passwordText" : "Welcome@123"

}

Curl request: curl --location --request POST 'http://192.168.1.193:8080/webhook/changePassword' \

--header 'Content-Type: application/json' \

--data-raw '{

"request": {

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

"passwordText" : "Welcome@123"

}

Response: NA

Pre provision

Purpose : This web hook is used to do some events before assigning applications to a user.

Input Needed :

{

"request": {

"policyMap" : "email",

"form" : "",

"applicationId" : "620231fee789224ec1cec3dd",

"roleList" : [],

"action" : "Application Create",

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Curl Request:

curl --location --request POST 'http://192.168.1.193:8080/webhook/preProvision' \

--header 'Content-Type: application/json' \

--data-raw '{

"request": {

"policyMap" : "email",

"form" : "",

"applicationId" : "620231fee789224ec1cec3dd",

"roleList" : [],

"action" : "Application Create",

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Response : NA

Post provision

Purpose : This web hook is used to do some events after assigning applications to a user.

Input Needed :

{

"request": {

"policyMap" : "email",

"form" : "",

"applicationId" : "620231fee789224ec1cec3dd",

"roleList" : [],

"action" : "Application Create",

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

"isSuccess" : true,

"uid" : "5f36283bc193991db0990d3e"

}

Curl response :

curl --location --request POST 'http://192.168.1.193:8080/webhook/postProvision' \

--header 'Content-Type: application/json' \

--data-raw '{

"request": {

"policyMap" : "email",

"form" : "",

"applicationId" : "620231fee789224ec1cec3dd",

"roleList" : [],

"action" : "Application Create",

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

"isSuccess" : true,

"uid" : "5f36283bc193991db0990d3e"

}

Response : NA

Policy map

Purpose : This web hook is used to do some events on policy map while assigning the application to a user.

Input needed :

"request": {

"targetAttribute" : "email",

"cymmetrifield" : "email",

"defaultValue" : "example@gmail.com",

"formVeriable" : "",

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Curl request :

curl --location --request POST 'https://52.66.206.31:8080/webhook/policymap' \

--header 'Content-Type: application/json' \

--data-raw '{

"request": {

"targetAttribute" : "email",

"cymmetrifield" : "email",

"defaultValue" : "example@gmail.com",

"formVeriable" : "",

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Response :

{

"response": {

"mappedValue": "valid"

}

Run deprovisioning

Purpose : This web hook is used for deprovisioning applications when users get updated .

Input needed :

{

"request": {

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Curl request:

curl --location --request POST 'https://52.66.206.31:8080/webhook/runDeprovision' \

--header 'Content-Type: application/json' \

--data-raw '{

"request": {

"user": {

"assignedGroups": [],

"provisionedApps": {},

"securityQuestion": {},

"country": "India",

"firstName": "Shreyash2",

"lastName": "Pande2",

"login": "shreyash2",

"userType": "Employee"

}

Response:

{

"response": {

"data": true

}

Archive

Introduction to Cymmetri Cloud 2.0

FAQ

Adding the Application

Accessing the Applications Menu

Understanding the applications supported by Cymmetri

Adding Application

Conclusion

Supported Web Browsers

Forgot Password & Unlock Account

Cymmetri Error codes

Help

Getting Started with Cymmetri Cloud 2.0

What is Cymmetri?

What is Cymmetri?

Starting your Cymmetri Cloud 2.0 Trial

Accessing Cymmetri Cloud

First Time User Registration

Logging in as an end user

Setting up Multi-factor authentication rules for Login

Administration

Reports and Analytics

My Workspace

Getting Started

Introduction

User Navigation

How to use the My Workspace

Dashboard

My Access

Inbox

Team

Session Management

Application Management

FAQ

Support for Application Management

Supported Pre-configured Applications

Supported Connectors

Getting Started

Introduction to Application Management

Adding Applications

Single Sign On

Managing the Application Sign On Policy

Provisioning

Reconciliation

Assigning Application

Adding Applications to be managed by Cymmetri

Accessing the Applications Menu

Understanding the applications supported by Cymmetri

Adding Application

Conclusion

Configuring Connector Server

Java Connector Server

Installing a Java Connector Server

Create your execution environment

Test your execution environment

Configure your Java connector server

Running your Java connector server

Installing Connectors on a Java Connector Server

Using SSL to communicate with connector servers

Configure your application to use SSL

.NET Connector Server

Installing a .NET Connector Server

Configuring the .NET Connector Server

Additional Notes about configuration

Changing Trace Settings

Running the .NET Connector Server

Installing Connectors on a .NET Connector Server

Running Multiple Connector Servers on the Same Machine

SSO How to

Configure Single Sign On

Supported Single SignOn Mechanisms

Configuring Applications for Single SignOn

Configure SAML 2.0 Single Sign On

Service Provider initiated flow (SP initiated flow)

Configuring application to use Service Provider initiated flow

Testing the Service Provider initiated flow

Identity Provider initiated flow (IdP initiated flow)

Description

Configuring application to use Identity Provider initiated flow

Testing the Identity Provider initiated flow