1 of 100

3.0.0 Getting Started

What is Cymmetri?

Cymmetri is a Converged Identity & Access Management Platform and 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.

Release Notes

Version: 3.0.0

New Features

General Features

Updated Cymmetri framework to set default IST timezone.
Self-service Mobile App Introduced
External Components using Cymmetri Authentication added:
- Windows Credential Provider using Cymmetri 2FA authentication
- Cymmetri AD Password Filter
Global Session Management and Login configurations can be configured from a single location in Authentication section

Provisioning

Suspend and Resume Users to ensure appropriate removal of assigned business applications
Auto userId (loginId) generation
User Decommission if inactive for the specified duration
Teams configuration added for distributed access support.
On Behalf of feature introduced to support distributed administration.
On user registration unknown/new department and designation will be added to Cymmetri automatically.

Bulk Import

Bulk Import feature introduced, support for the following types of import added:
- Bulk Application Assignment
- Bulk Application Role Assignment
- Bulk Manager Assignment
- Bulk Group Assignment

Workflow

Workflow approver selection.
Workflow configuration support added for setting multiple stages.
Custom workflow configuration added for below events, with rule based workflow execution support.
- User Creation
- Application Provisioning
- Application Deprovisioning
- Application Role Setup
- Application Update
- Workflow Setup
- Decommission Device
Workflow Self Approval, configuration support added to set self approver rules, below are the supported workflows
- Application Update
- Application Provisioning
- Application Deprovisioning

MFA

FIDO Authentication introduced as a new MFA mechanism
Support for Adaptive MFA added as an Experimental feature

Risk Engine

Active Directory Configuration
Scheduled Risk Evaluation
Reports

Password Filter

Password Filter support for Active Directory which is used to intercept password changes on Active Directory, and pass it to Cymmetri for provisioning purposes

SSO

Support for uploading of x509 certificate for SAML configurations
Support for configuring protocol binding, relay state of service provider
Support for Policy Mapping
Option to regenerate certificate and keys of SAML and listing of keys added
SAML configuration is separated for centralised control and ease of configuration
CIDR (Classless Inter-Domain Routing) feature for added sso applications

Webhooks

Web hook APIs secured with token based access
Two level encryption support with PKCS standard for authentication
Hook support added for below events
- Change Password
- Reset Password
- Forgot Password

PAM

PAM MFA support added
- Support added to configure multiple policies.
- Added meta tag support for policy rules.
- Latest updated policy will be considered if multiple policies matched

Starting your Cymmetri Trial

Start by clicking on the link register.cymmetri.io 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 redirected to your domain to create the 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
Enter your username and press Next

Enter your password and proceed with the setup of your tenant by clicking on the Login button

Choose applications from the application catalogue, click on the application icon for all the applications you wish to add. 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:

Learn how new users can access your tenant.
Manage your users and groups.
Manage your applications.
Check out your workspace.
Add your own branding.

Admin Dashboard

Cymmetri dashboard provides administrators with a centralized and visual representation of key information and controls related to identity management, access governance, and administration.

The dashboard serves as a command center for overseeing and managing the identity lifecycle, compliance, and other aspects of identity and access governance within an organization.

Upon Logging in the admin is landed on the dashboard where he can see the following:

Shortcut to configure recently added application - Configuration the application means adding roles, defining provisioning, reconciliation, SSO and so on
Users Activity - Total Successful user logins in Cymmetri on that day
Accounts Locked - User account locked event on that day
Users Onboarded - New users being onboarded in the system on that day
Password reset - Password reset activity in the system on that day
Authentication stats - Number of successful and failed login attempt in a timeframe
App Identity - It displays the application reconciliation activity with respect to the users.

Cymmetri also displays some important system KPIs to the admin as shown below

Application - Number of applications onboarded in Cymmetri

Active Users - Total number of active users in the system

Total Users - Total number of users onboarded in Cymmetri

Roles - Total application roles created in Cymmetri

Workflows - Total approval workflows created in Cymmetri

Password policy - Total number password policies created for user authentication in Cymmetri

Rules - Total rules created in System for provisioning, MFA, approval workflows, etc.

Users unlogged - Number of users who have never logged in to Cymmetri

Additionally, there are some useful system shortcuts placed on the right side of the page to make faster business decisions.

Accessing Cymmetri

To access Cymmetri, users must use a web browser, such as Google Chrome or Safari, and enter the appropriate address in the address bar as shown below:

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

Example: https://helpdocs.cymmetri.com/login

Once the address is entered it opens a page as shown below, where the users may enter their username and password to access Cymmetri.

Supported Web Browsers

Cymmetri supports the following web browsers:

Chrome

Firefox

Edge

Safari

Version of specific browsers supported by Cymmetri are:

DESKTOP:

Browser

Version

MOBILE:

Browser

Version

Cymmetri Error Codes

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

ERROR CODE

ERROR TEXT

Help

The Cymmetri Help Page serves as a vital resource, offering users a comprehensive documentation hub that breaks down all the features and provides step-by-step configurations for various functionalities.

To access this valuable documentation, you can visit https://help.cymmetri.io directly. Alternatively, you can simply click on the help icon located at the bottom left of your Cymmetri tenant screens.

Key Features of the Help Page:

Comprehensive Feature Explanation: The Cymmetri Help Page covers all the features of the platform in a straightforward manner. Whether you are a beginner or an experienced user, you can find detailed explanations of each feature, ensuring you have a clear understanding of its purpose and functionality.
Step-by-Step Configurations: One of the highlights of the Help Page is its provision of step-by-step configurations for various features. This means you can follow a simple, structured guide to set up and customize different aspects of Cymmetri according to your specific needs.
User-Friendly Language: The documentation is crafted in a manner that balances technical precision with user-friendly language. You won't find unnecessary jargon, making it accessible for users with varying levels of technical expertise.

Personalization

General Configuration

In this section within Cymmetri a range of general or broad configuration settings and options are managed. These settings encompass various foundational configurations that affect the overall behavior of Cymmetri.

There are different system configurations in Cymmetri mentioned below:

On Behalf

Time Based

In the Time-Based configuration, system administrators have the capability to determine whether the system will send repeated notifications to users based on the number of days remaining, as specified in the 'Send Notifications before' field. This occurs when an application is assigned to the user as a time-based application and is about to expire.

Email Config

These settings and configurations within Cymmetri are specifically related to the management and customization of email-related functionalities. This configuration area allows administrators to set up, manage, and customize the email communications as per the organization's needs.

Suspend Config

Within the Suspend Config section, administrators have the ability to determine the duration a user remains in a suspended state before transitioning to the archived users section. This can be specified using the "Suspend After" setting.

Scheduler Integration:

The system incorporates a scheduler feature, enabling administrators to automate the transition of users from the suspended state to the archived state. The scheduler runs within defined time frames, streamlining the management of user statuses.

As an example, if the "Suspend After" configuration is set to 0 days, a user will promptly move to the archived users section upon suspension. This allows for flexibility in tailoring user management to specific organizational needs.

Workflow Preference Config

Within the Workflow Preference Config, administrators have the ability to specify the visibility and editability of workflows associated with user access requests for a particular application. This setting allows for tailored control over how approvers interact with the configured workflow.

Visible to the User:

When this option is selected, approvers for the requested application are visible to the user initiating the access request. Transparency is maintained throughout the workflow process.

Hidden from the User:

Opting for this configuration ensures that approvers for the requested application remain hidden from the user. The workflow operates discreetly in the background without user visibility.

Editable by the User:

If this preference is chosen, users initiating access requests have the ability to select approvers based on their availability, providing a more dynamic and user-centric workflow experience.

This functionality applies if a workflow has been configured for the specified application, offering flexibility in managing user access requests in alignment with organizational requirements.

The approvers mapped in the workflow can only be edited only if they are part of the "user list" in workflow configurations.

In conclusion, if the workflow preference config is set to Editable, the requester will only be able to select the approver from the workflow if the approvers are part of a user list.

Reset Password OTP Config

This setting involves whether an OTP (One-Time Password) is required as an additional verification step when users attempt to change their passwords.

User Decommission Config

The User Decommission Config is a vital feature in Cymmetri, allowing administrators to automate user decommissioning based on login activity.

In this configuration, actions are triggered if the user hasn't logged in to Cymmetri in n number of days

Config Days: Set the threshold for user inactivity in terms of days. Users who have not logged in for the specified duration will be subject to the defined actions.

Actions: Choose from three distinct actions to be taken when the specified inactivity threshold is reached:

None: No action will be taken based on user inactivity.
Inactive: Users exceeding the configured inactivity period will be marked as inactive.
Delete: Users who have not logged in for the specified duration will be suspended from the system.

Syslog Configuration

Syslog configuration in Cymmetri allows for the seamless integration of logging and event information with external Syslog servers. By defining specific parameters, administrators can ensure that critical system events, user access information, and other relevant data are transmitted in real-time to a Syslog server.

Syslog Config fields:

Syslog Name - Assign a unique name to this Syslog configuration
App Name - Specify the application name associated with this Syslog configuration.
Server Host Name - Enter the hostname or IP address of the Syslog server that will receive log messages
Server port - Define the port number on the Syslog server where log messages will be sent.
Protocol - Choose the preferred protocol for Syslog communication - TCP or UDP.

In configuring these parameters, administrators tailor Cymmetri's interaction with external Syslog servers, optimizing the logging process to meet organizational needs.

Webhooks Configuration

Webhooks in the Cymmetri's admin module provide a powerful mechanism for real-time communication and integration with external applications or services. Administrators can configure various webhook settings to enhance the system's functionality and streamline interactions with external components.

Webhook Configs:

Protocol - Communication protocol - (Static field)
Method - HTTP method for webhook requests - (Static Set to post)
Server - Enter the server or endpoint URL where the webhook payloads will be delivered.
Server Context path - provide the context path for the specific service within the server.
Secret - This secret key, known to both Cymmetri and the external service, helps authenticate the webhook requests.
Token Expiry Minutes - Define the duration (in minutes) for which authentication tokens associated with webhook requests are valid.

Application Request Config

This setting determines if a user has the ability to initiate requests for new applications through the Cymmetri self-service page.

When the status is active, the user will see the "Add New" button on the "My Access" page within the "My Workspace" section. By clicking this button, the user can submit an access request for additional applications.

Threshold Delete Config

The Threshold Delete Config is a critical component in Cymmetri, governing the maximum number of users that can be deleted from the system in a single day.

This configuration provides an additional layer of control to prevent unintended mass deletions and ensure the security and stability of Cymmetri

Admins

Cymmetri platform has six different admin roles with various levels of access to the various menus and resources on the administration portal of the Cymmetri.

In addition to these six admin roles, Cymmetri also supports three different privileged user roles that grant varying levels of access (read, write, report) to privileged users within Cymmetri.

Administrators

The various admin roles on the Cymmetri Identity Platform may be described as follows:

Organization Administrator

This is the so-called 'super admin' administrator role in the Cymmetri platform. Administrators with this role have the authorization to modify any settings or make changes to the tenant.

Domain Administrator

This is a slightly less privileged administrator. Most tenant-wide system settings, such as the configuration of SMS and email providers (when configured by the tenant), are restricted for domain administrators. All other configurations can be viewed and edited by administrators with the Domain Administrator role.

Application Administrator

An administrator with the role of Application Administrator has access to Identity Hub configurations, including Application, User, and Group configurations. The Application Administrator can map users and groups to applications and has the ability to edit all configurations related to Application Management.

Report Administrator

An administrator with the role of Report Administrator has access to the Reports menu, which includes the ability to view, modify, and add new reports.

Help Desk Administrator

Helpdesk administrator has access to a very limited set of administrative functionalities, such as, reset password of end-user, remove configured Multifactor authentication options, and other such common use-case

Read Only Administrator

All administrative users have editing access to the various administrative sections of the Cymmetri platform. However, administrators with the "Read Only Administrator" role do not have editing access to any of the settings or configurations; they only have "Read Only" access to the administrative section.

PAM Write Access

PAM Write Access in Cymmetri grants users the privilege to connect to servers via RDP or SSH and perform write or modification actions on those servers. Users with PAM Write Access have the ability to make changes, update configurations, and perform tasks that involve altering data or settings on the connected servers. This access level is typically assigned to administrators and IT personnel responsible for making configuration changes or updates on various servers within the Cymmetri environment.

PAM Read Access

PAM Read Access provides users with the ability to connect to servers using RDP or SSH and view the content and configurations on those servers. However, users with PAM Read Access do not have the authority to make modifications or changes to the server settings or data. This level of access is suitable for individuals who need to monitor server activities, check logs, or retrieve information from servers without the need to alter any server configurations.

PAM Report Access

PAM Report Access is designed for users who require access to PAM-related reports without the need to connect to servers via RDP or SSH directly. Users with PAM Report Access can generate and access reports that provide insights into server activities, access logs, or other relevant data within the Cymmetri. Such users can also configure schedulers to send timely reports to various other users. This level of access is beneficial for auditors, compliance teams, or individuals focused on analyzing server-related information for reporting and auditing purposes.

Adding a New Admin

Follow the steps mentioned below to promote a user as an admin in Cymmetri platform.

Click on the Configuration menu on the right-hand side

Now click on the Admins sub menu within the Configuration menu

Click on the "+Add New" new button to add a new administrator

To assign an administrator role to a user, search for the user and then click the 'Assign' button.

Select the chosen administration role and click on Save

Administrator has been assigned the role as “Report Administrator”.

All Admins

All admins is a section where various Cymmetri admins listing is displayed to the admin user

Masters in Cymmetri

Masters are key-value pairs that can be defined for the entire tenant. The key(name) in this context refers to the label to be shown on the Cymmetri User Interface, and the value is the backend identifier used to reference this field in various processes, rules, and policies defined in the Cymmetri platform.

Cymmetri platform allows for configuring a number of masters in the system, the major classification among which is Global masters (which allow for creating master key-value pairs that may be used for various situations, such as creating a new department, designation, and other custom attributes for users in the system) and Zone masters (which are network configurations that may be used to whitelist or blacklist user access onto the platform as well as act as a source for adaptive Multi-factor authentication).

Global Masters

These are system-wide key value pairs primarily used to setup key value pairs referring to various masters as given below:

Types of Global Masters:

Adding a new Master

Follow the steps below to Add a New Master:

Click on the "+Add New" button to add a new master of any category mentioned above.

Enter the Name and Value for the new Master, then select the type of master you wish to create and enable the active toggle button to make the master active. Once all values are entered click on Save button

A new Global Master is successfully created in the selected category

Zone Masters

Zone masters indicate the network zones that may be used for blacklisting or whitelisting access to the Cymmetri Identity platform deployment. It may also be used for detecting users from certain zone and assign relevant multi-factor authentication policies.

Zone Name: Used to refer to a zone in other configurations on the Cymmetri platform.

Inactive/Active: Toggle button to check whether the zone is active (configurable as a condition for other rules on the Cymmetri platform.)

Gateway IP: Refers to the Gateway IP address for the network zone.

Proxy IPs: Proxy Server IP addresses that may be used to be directed to this network or the IP addresses outside of the zone that would indicate a connection from this zone.

For adding a new Zone Master or for editing an existing one, Fill all the mandatory details in the screen as shown above, click on the enable toggle button and finally click a “Save” button.

Personalize Notification Templates

Notifications are triggered from the Cymmetri platform for various actions occuring on the platform either through direct action by the end-user or by the virtue of some backend action (such as running of a scheduler for a campaign). Cymmetri platform ships with default notification templates that may be modified by the administrator using the following process:

Access the notification templates menu by clicking on the configuration menu on the left-hand side menu bar and then clicking on the Notification templates pop-up menu.
Click on the eye icon to preview the corresponding template
Values in <> anchor tags and ${} reflect macros.
Click on the pencil icon to edit the template.
We may treat this template as an email, and edit the subject of the mail.
By default, the email notification will be sent to the corresponding affected end-user, but selecting the toggle option for “Send notification to Reporting Manager” will also copy the mail to the Reporting manager of the affected end-user, allowing for offline followup for the notification.
The administrator may edit the HTML using the provided HTML editor to add/change any template button/text/background. The macros required for the particular template are already provided in the sample default notification template.
Click on the Save button to save the notification template.

Tenant Branding

Tenant branding in Cymmetri allows you to personalize and enhance the visual identity of your environment. With tenant branding, you can customize the appearance of your platform, including logos, color schemes, and even tailored messages, aligning it with your organization's branding guidelines.

This not only creates a cohesive and professional user experience but also reinforces your brand's presence throughout the Cymmetri environment. It's a powerful tool for organizations looking to maintain a consistent and recognizable image while utilizing Cymmetri's identity and management capabilities.

The Cymmetri platform allows a certain level of customization to your tenant from the administration panel. This includes the ability to modify the default Cymmetri branding scheme to your own Organization’s branding scheme.

Your Organization Name and Tagline
Your Organization Logo
Your Organization Branding Colors (Primary, Secondary, Accent Colors)

Configuring your tenant branding

To access the branding menu, first click on the Configuration menu on the left-hand side and then proceed by clicking on the Branding menu item.
Start the configuration by entering your Organization Name and Tag Line
Proceed by adding a Welcome text and Welcome Tagline and select whether the Cymmetri help icon should be visible to the user or not
Proceed by adding your URL to the Website text box and click on “Fetch Brand”.
If your organization’s branding is available, the logo and the corresponding color scheme will be displayed in the menu below.
If your branding is not available, you may configure it yourself by uploading your logo and editing your primary color, secondary color, and accent color.
Click on Save and Sync Server button to make the branding configuration apply to the entire website.

The configuration will be applied in a few seconds to reflect your branding.

In Cymmetri, the administrator now has the option to select the "Reset to default theme" button, allowing them to revert to the original theme.

Custom Attributes

Custom Attributes may be added for all user entities in your Cymmetri Platform. This allows organizations to add custom user attributes, that are used across the applications in the organization.

For example, your organization has a custom attribute that captures and uses the local language of your employees and vendors for the purpose of providing local services. This attribute may be stored in your Active Directory, and may need to be synchronized to your organization’s other applications during the course of an employee or vendor’s employment.

Cymmetri platform allows the administrator to define custom attributes on a tenant-wide level.

Custom attributes can be used at various places like when creating a user, as a filter when searching for users, and is visible in the others section of user info

Configuring Custom Attributes

To start configuring custom attributes, click on the Configurations menu on the left-hand side and then click on the Custom Attributes menu.

Click on the Add New button to start adding a custom attribute
Fields to be updated:
1. Name/ Key: refers to the label assigned to the custom attribute.
2. Description: allows you to provide additional details or notes about the custom attribute for reference and clarity.
3. Status: Allows to activate the custom attribute. Only if it is set to active, is the attribute available to use in the User Object.
Note: A custom attribute once created can only be set to inactive, it cannot be deleted.

Identity Hub

Managing Users and Groups

User Management

The User Management interface in Cymmetri provides an intuitive and efficient way to manage the users within Cymmetri. The interface is designed to support both list and card views, allowing administrators to easily navigate through user profiles according to their preference.To access the User Management page, navigate through: Identity Hub -> UserFeaturesThe UserManagement Page provides various features which eases the user management.

View Modes: Users can toggle between a list and a card view, providing flexibility in how information is displayed.
Search Functionality: Quickly find users with the integrated search feature, saving time and improving manageability.
Advanced Filtering: The granular filtering capability ensures that administrators can pinpoint users based on specific criteria, making user management tasks more streamlined. List of users can be narrowed down the using various filters, including:
- Account Status
- User Status
- Users' Login Status
- Location
- Department
- Designation
- Usertype
- Custom Attributes

User Information Display

For each user, the following information is prominently displayed:

Display Name: The full name of the user as it appears in the organization.
Email: The user's primary email address.
Mobile Number: Contact number of the user.
User Status Indicator: An intuitive green or red dot next to the display picture indicates whether a user is active or inactive, respectively.

Contextual Actions

A context menu associated with each user profile offers a suite of actions, enabling administrators to manage user accounts directly from the interface. Available actions include:

Reset Password: Securely reset a user's password.
Mark Inactive: Change a user's status to inactive.
Assign Group: Add the user to specific groups for access control and organizational purposes.
Assign Application: Allocate applications to the user as per their role and requirements.
Edit Info: Update user information such as email, mobile number, and other personal details.
Delete User: Remove the user from the system entirely.

User Detail

This page is designed to provide a comprehensive view of an individual user's information, facilitating easy access and management for administrators.

User Profile Overview

The top section of the User Details Page showcases the following crucial user information:

Profile Picture

The user's profile picture is prominently displayed, offering a visual identification of the user. This feature aids in personalizing the user experience and making navigation more intuitive.

User's Status

Right next to the profile picture, users can find the current status of the user, which indicates whether the user is Active, Inactive, or Pending. This status helps in quickly understanding the user's engagement level.

This is a unique identifier for the user within the system. It serves as a key piece of information for various administrative processes, including user tracking, support, and security checks.

Email ID

The user's Email ID is displayed, providing an essential communication link. It is used for sending notifications, password resets, and other critical communications.

Mobile Number

The user's mobile number is listed if provided. This number can be utilized for two-factor authentication, urgent alerts, or direct contact purposes.

This structured format ensures that an administrator or any authorized viewer can quickly access and understand a user's essential information without navigating through multiple pages.

User Info Page

This page provides a comprehensive overview of the user information managed within our system. The data is categorized into several sections to facilitate easy access and understanding of each user's profile. These sections are detailed below.

Basic Information

First Name: The user's given name.
Middle Name: The user's middle name, if applicable.
Last Name: The user's family name.
Grade: The user's grade (a set values need be defined for this field in Masters) .
Designation: The specific title or position the user holds.
Date of Birth: The user's birth date.
Age: The user's current age, calculated from the date of birth.
User Type: Classification of the user based on the user types defined in the system.
Login ID: The unique identifier used by the user to access the system.

Contact Information

Country: The country where the user is located.
City: The city within the country.
Mobile: The user's mobile phone number.
Email: The user's email address, used for electronic correspondence.
Landline: The user's landline phone number, if applicable.
Address: The user's full postal address.

Organization Information

Employee ID: A unique identifier assigned to the user within the organization.
Department: The department to which the user is assigned.
Start Date: The date when the user commenced their current position.
End Date: If applicable, the date when the user's current position will or has ended.
Manager: The user's direct supervisor or manager.

Custom Attributes

Additionally, this page may display values for custom attributes specific to our organization. These attributes allow for the capture of information not covered by the standard categories but deemed necessary for our operations.

This comprehensive user information page ensures that all pertinent data regarding an individual within our organization is readily accessible, facilitating smooth operations, management decisions, and communication.

Applications Page

This page is designed to streamline the management and assignment process of applications for users. It offers a section where you can easily view all your assigned applications along with their current status. Additionally, it allows for the straightforward assignment of new applications to your profile.

Viewing Assigned Applications: Upon accessing the page, you will be presented with a list of applications currently assigned to you. Each application tile gives a snapshot of the application's status, enabling you to quickly assess which applications require your attention.
Assigning New Applications: Should you need to add more applications to your list, the process is simple. Just click on the Add New Button located on the interface. This action opens up a selection window where you can choose additional applications that you wish to assign to the user.

Searching for Applications: To facilitate ease of access, a search function is incorporated into the interface. This feature allows you to quickly find specific applications by typing the name or part of it into the search bar, saving you time and effort from manually scrolling through the list of applications.

Note: In instances where an application has not been successfully assigned, the interface provides direct actions to resolve the issue without needing to navigate away from the page. Each application tile includes an ellipse (...) menu with two options:

Retry : If an application's assignment process encounters an issue, you can select this option to attempt assigning the application again.
Delete : If the assignment issue remains unresolved or if you no longer wish to keep the application, you can choose to remove the application from your list entirely.

Groups Page

This page provides an overview of the groups to which a user is assigned, reflecting the current status of each.

Viewing Assigned Groups and Their Status

Upon accessing the page, users are presented with a list of all the groups to which they are currently assigned. Each entry includes the group's name, description, number of users in the group and number of applications assigned to the group.

Adding New Groups

To enhance the user's role or access within the system, the Add New Button is prominently positioned. This option allows users to be added to more groups, expanding their access and functionalities within the application. The process is designed to be straightforward, guiding the user through a simple process to ensure accurate group assignment.

Editing Group

This menu option found within the ellipse menu takes you to the groups page whether you may edit any information related to the group

Removing Group Memberships

Equally important is the capacity to manage the departure from groups, which is facilitated by the Delete Group option. Also found within the ellipse menu, this feature does not delete the group itself but rather unassigns the user from the selected group. This action ensures the user's access and permissions within the application are precisely tailored, maintaining security and relevance.

User Activity Log Page

This page shows user specific audit log for all the various actions and activities performed by the user

User's Settings Page

Status: You can change the status of users and accounts in our system to manage access and control.

For Users:

Locked: Stops user access temporarily. This is used for security reasons or if there are too many failed login attempts.
Unlocked: Gives access back to the user, allowing them to log in and use the system.

For Accounts:

Active: The account is in use, and everything works normally.
Inactive: Temporarily not in use but can be activated again.
Delete: The account is deleted and moved in suspended accounts

Reset Password: A Generate button allows administrator to reset password for users, which can then be copied to the clipboard if required.

RBAC: This section can be used to assign tenant wide roles defined in the master to the user.

Secret Questions: This sections shows a list of secret questions selected by the user

Additional MFA: Administrators can view the MFA mechanisms configured by the user as well as removed the configured MFA if required for a specific user

Trusted Devices by User

If Adaptive MFA is configured for users and a configuration for Device Trust is done, Cymmetri maintains a list of Trusted devices that satisfy the conditions of the Device Trust configuration. This list of devices trusted based on the configuration done by the admin are listed on this page with the following information about each device: Browser, OS, Created At, Trusted, Action(remove device)

User's Sessions

This page provides Cymmetri administrators with the capability to monitor and manage all user sessions, It provide the following information: Browser, OS, Created By, IP Address, Created At, and Action (delete session). A user may have multiple session entries if the Multiple Session configuration is enabled.

Managed View

The Managed View page shows the user data based on various provisioning applications assigned to user, This page shows the Attribute Name, Managed System Value and IDM Value

Attribute Name: Attribute name as defined in the policy attribute page of the provisioning application
Managed System Value: Value as saved in the provisioning application
IDM Value: Value as saved in Cymmetri

Delegation

In Cymmetri, one of the features available to users is the ability to delegate self-service access. This capability enables users to assign their access rights and responsibilities to other users temporarily. Ideal for scenarios such as vacations, business trips, or whenever a user needs someone else to manage their duties without forfeiting their credentials or compromising security.

This page shows the delegation provided by the user, this may be currently in progress or the delegation which was last completed.

The page shows the status of the Delegation (INPROGRESS, COMPLETED), Designated To, Start Date and End Date and the list of Excluded Applications(if any)

Create Users

While users may be imported and synchronized 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 “+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.
Optionally a group can be assigned to the user.
And also applications can be assigned to the user.

Once all the above steps are completed successfully the user is 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 >Groups menu on the left-hand side.

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

Group Name: Indicates 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.

Once all the details have been entered click on Save button and a new group is created.

Importing Users

Users may be imported into the Cymmetri platform using the bulk Import Users feature.

Importing Users

For Importing Users in Cymmetri platform administrator need to click on Identity Hub > User menu and then click on the Bulk Import > Import Users button.

A screen pops up that lets you select the csv file you want to upload to import the users, Upload the csv file, you may also use the sample data file available and modify it to match your user details.

Click on the Upload File button and select the file you wish to import

Once the file is selected ensure that the default parameters select match your requirement else you may change these parameters as per your requirement and click on Next button.

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

Scroll down and click on the Import button. Note: A "Skip user workflow" check box is available to skip execution of any user workflow configured for creation of users, if not selected it may trigger user creation workflow and the process of importing users may slow down due to the numerous approvals that the approver might have to do.

Once Imported results of successfully Imported Users, Duplicate Users or any error that occurred during import can be see in Logs > Import History page

Assigning Users to Groups

Assigning Users to a Group

Users once created in the Cymmetri 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.

When assigning users to groups there can be various approaches which can be used:

Adding User to Group (from the Group Page)
Assigning a Group to a User (from the User's Page)
Bulk Assigning Users to a Group (Using Group Assignment on Group Page)

Adding User to Group

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

Now Go to the Users Page and click on +Add button to get a list of users to add to the group

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

Once assigned the user can be seen on the Users page of the Group as shown below:

Assigning a Group to a User

For this approach the Administrator needs to go to Identity Hub > User page and then select the user from the list to whom the group needs to be assigned

Go to the user's page and select the Groups menu and click on "+Assign New" button

This opens a pop up window where a list of all groups is visible

Click on the assign button and the group is assigned to the user or you may say the user becomes a part of the group

Bulk Assigning Users to a Group

For this approach the Administrator needs to go to Identity Hub > Group page and then click on the Group Assignment button

A screen pops up that lets you select the csv file you want to upload to import the users that needs to be assigned to the group. This csv file needs to have one column that contains login id of users; Upload the csv file, you may also use the sample data file available and modify it to match your user's login id.

Once the file is selected and uploaded next you need to select the group to which you want to assign the users.

After selecting the group the column in the csv file needs to be mapped with the Cymmetri login column.

Once mapped click on the import button and the users would be mapped to the assigned group provided the login id is correct

Results of successfully Imported Users, Duplicate Users or any error that occurred during import can be see in Logs > Import History page

Delegation

Setting up Delegation

Delegation as a process in the Cymmetri platform refers to the ability of any end-user to delegate their responsibilities to any other end-user on the platform. 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 menu item.

For any user to be able to delegate their work to other users, the user should be added to the delegation users list; To Add Users to the delegation list so that they can delegate their activities, click on the Assign New button and select one or more users to add to this list

The User and Assignee Consent sections allow organizations to align task delegation practices with their unique policies. This customizable feature empowers administrators to define specific consent texts, ensuring that both the user delegating a task and the delegatee receiving it acknowledge and agree to these terms.

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 (delegatee).This consent will be recorded in the Cymmetri backend for audit logging purpose.

Similarly, the assignee consent will be recorded when the end-user (delegatee/assignee) logs into the account for their manager (delegator/user).

Here's how it works:

Administrator Configuration: Administrators can craft consent texts tailored to their organization's requirements. These texts typically outline the responsibilities, expectations, and any legal or compliance aspects associated with task delegation.
User Perspective: When a user decides to delegate a task to someone else, they will be presented with the customized consent text. The user must carefully review and accept the terms before proceeding with the delegation process. This step ensures that the user is aware of the implications of task delegation and is willing to proceed.
Assignee Perspective: On the other side, the delegatee who is about to receive the delegated task will also be presented with relevant consent text. They must thoroughly read and accept these terms before taking on the responsibility. This step helps establish clarity and accountability for the delegatee.

Delegating Work to Delegatee

For any user to be able to delegate their work to other users, the user should be added to the delegation users list; Check here how to Add Users to the delegation list so that they can delegate their activities.

Delegate Work to Delegatee

Following are the steps to delegate work to an delegatee:

The logged in user needs to go to their Settings Page by clicking on the user's username on top right

Once on the Settings Page user needs click on My Delegations menu

Note: My Delegations menu will appear only if the logged in user is added to the delegation users list.Here is how to Add Users to the delegation list.

Toggle Status: Enable the Toggle Status to Active

Start Date: The date from which the user is delegate the work

End Date: The date upto which the access is delegated

Delegated To: The user (delegatee) to whom the work is delegated. This dropdown populates the list of all users to whom the task can be assigned

Excluded Applications: List of applications whose access is not provided to the delegatee

Once all the details are filled the user is expected to accept the consent to be able to configure the delegation. The consent looks something similar to as show below:

Once confirmed the user needs to click on the I agree check box and save the delegation

Once save the delegatee can see and accept the delegation in their My Delegation Page under Settings.

Accepting Delegation

Upon receiving a delegation request, the user is notified via email and within the platform.

To view the delegated task the delegatee can go to Settings->Delegation to Me to see details about the delegated tasks and the user who has assigned the task

The user needs to click on the Accept button to accept the delegation. On click the Accept button an Assignee(delegatee) Consent is shown which the users needs to read and confirm. The Consent also shows details of the delegator and the duration of the delegation.

Once the user accepts the delegation the user sees a login button, to login into cymmetri as the delegator

On clicking the login button the delegatee is redirected to the delegator's My Workspace Dashboard.

The delegatee can access and perform actions on all the applications assigned to them and if any application is excluded during delegation they are not visible to the delegatee.

Suspended Users

The admin can delete the user from the users tab in identity hub section.

After the user is deleted, the user is moved to the suspended users tab.

In the section for suspended users, the administrator has two options: they can choose to

Resume User - Which relocates the user back to the all users section OR
Force Delete - Which transfers the user to the archived users section where retention of the user is not possible

Archived Users

This section stores and manages user accounts that have been archived or deactivated. These accounts are usually no longer active but are retained for historical or compliance purposes.

You can see the other condition when the users are moved to archived users here

All Users Session

This page provides Cymmetri administrators with the capability to monitor and manage active user sessions across the entire platform.

This functionality allows administrators to gain insights into ongoing user activities, view active sessions, and, if necessary, terminate or manage these sessions for security, compliance, or administrative purposes.

The admin can terminate all the user sessions at once or select them individually. The page also has a search option for the admin to search the desired user session

Authentication

Identity Provider

Internal IDP

Introduction

Cymmetri's Internal Identity Provider (IDP) is a powerful authentication solution that supports seamless integration with various Identity Providers (IDPs).

We will explore the configuration options for three types of IDPs:

Cymmetri,
Active Directory, and
LDAP.

The flexibility of the Cymmetri Internal IDP allows you to manage multiple IDPs of the same type, making it easy to adapt to diverse environments with different Active Directory/ LDAP instances.Cymmetri's Internal IDP aims to provide a centralized and adaptable authentication solution for your environment, supporting various IDP types.

To access Internal Identity Providers navigate to Authentication-> Identity Provider->Internal IDP

To customize the applicability of different IDPs, administrators need to configure Authentication Rules. These rules enable the configuration of various conditions. When these conditions are met, the corresponding authentication mechanism or IDP is used for user authentication.

Internal Identity Provider Configuration: Cymmetri

To access Internal Identity Providers navigate to Authentication-> Identity Provider->Internal IDP

Since Cymmetri is a default Internal IDP no configuration is needed for it. An administrator may still have an option to disable Cymmetri Authentication which can be done by editing the Cymmetri Authentication Internal IDP mechanism

An administrator may also change the Display Name and/ or Description as shown in the screen above.

Internal Identity Provider Configuration: Active Directory

Active Directory (AD) serves as a robust Identity Provider (IDP) in enterprise environments. It authenticates and authorizes users, facilitating seamless access to resources. AD centralizes user management, streamlining security protocols and ensuring efficient user provisioning.

Active Directory can be utilized in Cymmetri as an Identity Provider (IDP), leveraging existing AD user accounts to access Cymmetri, as the platform supports the LDAP protocol.

For configuring AD as an Identity Provider on the primary service needed is the Adapter Service.

The Adapter Service

The Adapter Service or Auth Adapter Service is exposed as a rest service which runs on https acts as an adapter to facilitate authentication using the LDAP protocol which is often employed for authentication purposes in various systems and every adapter service instance is called by the secret generated while installation/configuration of adapter service.

The rest endpoints are called by cymmetri-cloud AuthenticationService to connect to On-Prem AD/Ldap or cloud AD/Ldap. The AdaptorService is used to test connection, authenticate, change, reset password of an user.

Configuration

For configuring Active Directory as an internal IDP navigate to Authentication -> Identity Provider -> Internal IDP. Here you may either configure the already created AD Authentication instance or +Add New

In either cases a screen opens where you need to provide the below mentioned details

Name: AD Authentication
IDP Type: Active Directory
Description: A general description about the IDP type
Status: Active
Adapter Service Domain: Location (IP) of the server on which the Adapter Service is deployed
Adapter Service Secret: The secret generated while installation/configuration of adapter service
Base DN: Active Directory root domain name
Search Scope: A search scope for locating users in Active Directory

Once all the details are entered Save the changes and Test the Connection using Test Connection button.

For enabling Active Directory to be used as an IDP for specific set of users an Authentication Rule needs to be configured. Here you can see the steps on how to configure Authentication Rules.

Once the rule is configured, whenever a user matches the rule conditions, their credentials are verified against those stored in Active Directory. Upon successful verification, the user is granted access to log in to Cymmetri.

Internal Identity Provider Configuration: LDAP

Lightweight Directory Access Protocol (LDAP) serves as a important Identity Provider (IDP) in enterprise environments. It authenticates and authorizes users, facilitating seamless access to resources. LDAP is commonly used as a directory service for managing user identities and authentication information within an organization.

LDAP can be utilized in Cymmetri as an Identity Provider (IDP), leveraging existing user accounts to access Cymmetri, as the platform supports the LDAP protocol.

For configuring LDAP as an Identity Provider one of the primary service needed is the Adapter Service.

The Adapter Service

Configuration

For configuring Active Directory as an internal IDP navigate to Authentication -> Identity Provider -> Internal IDP. Here you may either configure the already created LDAP Authentication instance or +Add New

In either cases a screen opens where you need to provide the below mentioned details

Name: LDAP Authentication
IDP Type: Open LDAP
Description: A general description about the IDP type
Status: Active
Adapter Service Domain: Location (IP) of the server on which the Adapter Service is deployed
Adapter Service Secret: The secret generated while installation/configuration of adapter service
Base DN: LDAP root domain name
Search Scope: A search scope for locating users in LDAP

Once all the details are entered Save the changes and Test the Connection using Test Connection button.

For enabling Open LDAP to be used as an IDP for specific set of users an Authentication Rule needs to be configured. Here you can see the steps on how to configure Authentication Rules.

Once the rule is configured, whenever a user matches the rule conditions, their credentials are verified against those stored in LDAP. Upon successful verification, the user is granted access to log in to Cymmetri.

External IDP

Introduction

Cymmetri's External Identity Provider (IdP) feature allows you to authenticate user identities using different IdPs for various user types. This flexible configuration enables you to streamline access for both internal employees and external users, such as consultants, vendors, and their employees. In this documentation, we will guide you through the process of configuring an External IdP within Cymmetri's identity and access management system.

For internal employees, you can configure Cymmetri's Internal IdP mechanisms like Active Directory or LDAP. This allows seamless authentication for your organization's employees.

Whereas external users, such as consultants, vendors, and their employees, can be verified using popular External IdPs like Google, Azure, Salesforce, or any other supported IdP. This approach simplifies access for external parties while maintaining security and control.

Configuring External Identity Providers

To configure an External IdP in Cymmetri, administrator needs to provide the following information:

Name: A descriptive name for the External IdP configuration.
IDP Type: The type or provider of the IdP (e.g., Google, Azure, Salesforce).
Entity ID: The unique identifier for the IdP entity.
SSO Service URL: The URL where Single Sign-On (SSO) requests should be sent.
Destination: The location where authentication responses should be directed.
Protocol Binding: The protocol used for communication with the IdP (e.g., HTTP Post, HTTP Redirect).
Name ID Policy and Value: This policy defines the format and content of the identifier that represents the authenticated user. For example:
- Policy: email
- Value: email
Certificate: The certificate used for secure communication between Cymmetri and the External IdP.

In the upcoming sections we will learn step by step implemenatation of the various External IDP mechanisms:

Google:

Google serves as a robust external Identity Provider (IDP) through its Identity Platform. Leveraging various authentication mechanisms, it facilitates secure user authentication for Cymmetri. This allows users to sign in with their Google credentials, ensuring a seamless and familiar login experience. Google's IDP mechanism is adopted for its reliability and user-friendly authentication processes, thus making it a preferred choice for integration into Cymmetri as and External IDP.

Azure Active Directory (Azure AD):

Azure AD serves as a robust external IDP, facilitating secure access into Cymmetri. Employing industry standards like OAuth 2.0 and SAML, it enables Single Sign-On (SSO) and multi-factor authentication. Azure AD seamlessly integrates with Cymmetri providing easy identity management and ensuring compliance with modern security standards.

Salesforce:

Salesforce as an external Identity Provider (IDP) offers robust authentication and access control solutions. Utilizing industry-standard protocols like SAML and OAuth, Salesforce IDP ensures secure Single Sign-On (SSO) experiences.

Configuring External Identity Providers in Cymmetri gives you the flexibility to authenticate user identities using different IdPs tailored to specific user types. Whether it's for internal employees or external collaborators, Cymmetri's External IdP feature ensures secure and convenient access to your organization's resources.

External Identity Provider Configuration - Google IDP

Google Configuration:

Once in the admin section click on Apps > Overview

In the overview page click on Web and mobile apps tile to add a new custom app

On the Web and mobile apps page click on the Add app dropdown and then select Add custom SAML app to add the Cymmetri tenant as a custom app

Provide a relevant App Name, Optionally a description for the application can be provided. An App Icon can also be attached if required. Once entered click on Continue button

On the Google Identity Provider Detail page download the metadata file by clicking on the DOWNLOAD METADATA button. This metadata file needs to be used to get Entity ID, SSO URL and Certificate. Administrator can download the certificate here or later as shown here. Once downloaded click on Continue.

Once the IDP metadata and certificate is obtained the Service Provider(i.e. Cymmetri) details need to be provided. We need to provide the ACS URL and the Entity ID these details can be obtained from Cymmetri as shown here. No change need to be done for Name ID format and Name ID it can be kept to UNSPECIFIED and Basic Information > Primary email. Once done click on Continue

Attributes can be added on this creen which could then be sent as a SAML response to Cymmetri. These values can be used to create a user in Cymmetri if JIT provisioning is enabled on Cymmetri's side

Group membership information can also be sent by cinfiguring groups here and if the user belonged to the configured group. Once attributes and groups are configured click on FINISH.

Once you click on the FINISH button the below screen appears that shows the configuration details. It also shows various shortcuts to Test SAML Login, Download Metadata, Edit Details and Delete App

Download IDP Certificate

If the administrator does not download the certificate while configuring the custom application, it can be later downloaded. For the same the administrator needs to go to Security>Authentication>SSO with SAML applications. This will open the Security Settings page from where either the IDP details like SSO URL and Entity ID can be copied and IDP Certificate can be downloaded. These details can be used to configure the IDP in Cymmetri.

Cymmetri Configuration

Once Google IDP is configured, the administrator must proceed with the configuration on the Cymmetri side. To achieve this, the administrator needs to set up Cymmetri as a Service Provider and also incorporate Google as an external IDP.

The page here shows how to configure a Service Provider.

Once the Service Provider is configured next we need to configure Google as an external IDP.

Administrator needs to go to Authentication->Identity Provider->External IDP. Here you may either configure the already created google-idp instance or +Add New

In either cases a screen opens where you need to provide the below mentioned details

Name: Google IdP
IDP Type: Google
Entity ID: https://accounts.google.com/o/saml2?idpid=xxxxxxxxxxxx
SSO Service URL: https://accounts.google.com/o/saml2/idp?idpid=xxxxxxxxxxxx
Destination: https://<hostname>/spsamlsrvc/samlSP/SingleSignOn
Protocol Binding: HTTP Post (can also be set to HTTP Redirect if it is set so in Google IDP)
Name ID Policy:
- Policy: Email (This may change based on what is configured in Google IDP)
- Value: Email (This may change based on what is configured in Google IDP)
Certificate: Certificate downloaded from Google IDP
Logout Request URL: Need to mention the SingleLogoutService url from the metadata file if SLO (Single Logout) is configured in Google.
Logout Protocol Binding:HTTP Post (can also be set to HTTP Redirect if it is set so in Google IDP)
Service Provider Id: cymmetri (Need to the select the configured Service Provider as shown above)

Once all the details are entered Save the changes.

For enabling Google IDP to be used as an IDP for specific set of users an Authentication Rule needs to be configured. Here you can see the steps on how to configure Authentication Rules.

Once the rule is configured whenever a user matches with the rule conditions the user is redirected to Google screen and the user needs to provide his/her Google credentials to be able to login into Cymmetri.

External Identity Provider Configuration - Azure IDP

Setting up Cymmetri Service Provider for External Identity Provider Configuration

The page shows how to configure a Service Provider.

Navigate to External IDP in Identity Provider.

Select Azure-IDP.

Configure Azure AD for Creating Identity provider configuration

Now Login to Azure portal and select Azure Active Directory.

Navigate to Enterprise applications and select New application.

Create your own application and enter the name of the application.

Set up Single Sign On after creating the application using SAML.

Click on Edit basic SAML configuration.

Add Identifier (Entity ID) and Assertion Consumer Service URL from the xml file downloaded in step 3 (For Azure, Sign on and ACS URL is the same) and save the configuration.

Download the Certificate (Base64) from SAML Certificates.

Continue configuration of Identity Provider In Cymmetri Administration Console

Copy Azure AD Identifier from Set up, navigate to azure-idp in Cymmetri and paste it in Entity ID. Similarly, copy login URL and paste it in Single Sign On Service URL in Cymmetri.

Open the Base64 certificate downloaded in step 12, copy it and then paste it in x509Certifcate field in Cymmetri.

Select the created service provider in the Service provider Id field dropdown and save the changes.

Assigning Users

Assigning user to application in Azure Administration Console for allowing users to use Azure as External Identity provider

Navigate to Enterprise applications and select the application you created in step 8.

Go to Users and groups and select Add user/group and add the user.

Configuring JIT provisioning in Cymmetri Administration Console

If JIT provisioning needs to be enabled for Azure AD as external Identity provider, we may set it up using the steps below.

Navigate to JIT in external identity provider and enable JIT Configuration.

The following fields are mandatory in Cymmetri - firstName, lastName, login, userType, displayName, and email.

For Azure JIT configuration, the following mapping needs to be done -

First Name -
1. Application Field - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
2. Cymmetri Field - firstName
Last Name -
1. Application Field - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
2. Cymmetri Field - lastName
Login (Username) -
1. Application Field - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
2. Cymmetri Field - login
User Type -
1. Application Field - any string
2. Cymmetri Field - userType
3. Default Value - <will be one of Employee, Vendor, Consultant>
Display Name -
1. Application Field - http://schemas.microsoft.com/identity/claims/displayname
2. Cymmetri Field - displayName
Email Address -
1. Application Field - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
2. Cymmetri Field - email

In Azure Administration Console

The user will be redirected to the Azure portal to enter the Azure credentials.

Once the credentials have been entered properly in Azure portal, the user will be redirected back to Cymmetri and will be logged in successfully.

External Identity Provider Configuration - Salesforce IDP

Note: The link below shows steps as suggested by Salesforce to configure Salesforce as an Identity Provider: https://help.salesforce.com/s/articleView?id=sf.sso_sfdc_idp_saml_parent.htm&type=5

Here below the same steps are demostrated to use Salesforce as and Identity Provider and Cymmetri as a Service Provider.

Configuring Salesforce

For configuring Salesforce to be used as an IDP the Salesforce Administrator needs to login in Salesforce as shown below:

Once logged in the administrator needs to click on Setup on top right and then in the search bar on the right side search for Identity Providers. Once found click on Security Controls -> Identity Provider menu

When the Identity Provider page opens click on Enable Identity Provider button to enable Salesforce as and Identity Provider so that it can be used for authentication in Cymmetri.

When the Enable Identity Provider button is clicked it opens a page that asks you to choose a certificate. Select the default certificate here and click Save.

When saved it shows a warning message as below just click OK button and continue.

Once confirmed the screen as show below appears you may download the certificate and the metadata file here using the Download Certificate and Download Metadata buttons. These files can be downloaded later during the end the process which can be seen later in the documentation below.

The metadata file appears as below, this data is used later to configure the External IDP in Cymmetri.

The certificate file appears as below this is also needed when configuring the External IDP in Cymmetri.

Once the files are downloaded next to add the Service Provider the salesforce administrator needs to click on Service Providers are now created via Connected Apps. Click here link. The mentioned link allows to create a Connected App for Cymmetri which acts as a service provider in Salesforce.

The link above leads to the page below where a new connected app can be added. Following details need to mentioned to add a connected app:

Connected App Name: App Name (Cymmetri in this case)
API Name: Auto-populated based on Connected App Name field, can be changed
Contact Email: a valid contact email

Note: Other fields shown in the image below are optional and hence can be skipped.

Next on the same page there is a section called Web App Settings here click on Enable SAML to enable the SAML settings. Once enabled all the below mentioned details need to be provided.

Entity Id: A unique identifier for a SAML entity, such as a Service Provider (SP) or Identity Provider (IDP), within a federated authentication environment.
ACS URL (Assertion Consumer Service URL): The endpoint where a service provider expects to receive SAML assertions from an identity provider, facilitating single sign-on (SSO) in a federated system.
Enable Single Logout: A configuration option indicating whether the system supports single logout functionality, allowing users to log out of all connected services in a federated environment with one action.
Single Logout URL: The endpoint to which a SAML entity sends logout requests as part of the single logout process when a user logs out of the federated system.
Single Logout Binding: The protocol or method used to transmit single logout requests and responses between SAML entities, often specified as either HTTP Redirect or HTTP POST.
Subject Type: Specifies the type of subject identifier used in SAML assertions, such as transient, persistent, or bearer, indicating how the identity of the user is communicated between the identity provider and the service provider.
Name ID Format: Defines the format of the NameID element in SAML assertions, determining how the user's identity is represented, such as email address, X.509 certificate, or unspecified.
Issuer: Identifies the entity that issues a SAML assertion, typically the identity provider, and is included in the SAML assertion to establish trust between the entities in a federated system.
IDP Certificate: The public key certificate associated with the identity provider, used by the service provider to verify the authenticity and integrity of SAML assertions and messages.
Signing Algorithm for SAML Messages: Specifies the cryptographic algorithm used to sign SAML messages, ensuring the integrity and authenticity of the information exchanged between identity providers and service providers in a federated

The above mentioned details can be obtained by adding a service provider in Cymmetri as shown below. To know more about how to add a service provider in Cymmetri click here. Once created these details can be used in Salesforce as shown above.

Once all details are successfully added and saved the screen as below appears which shows the configuration details.

Administrator can click on Manage button (as shown above) to view SAML Service Provider Settings and SAML Login Information. Administator can also download metadata file here.

The downladed metadata file appears as below. The details mentioned in the metadata file are used to configure an External IDP in Cymmetri.

Based on the diverse profiles of users in Salesforce, the administrator needs to enable Connected App Access for these profiles. Here in this example access has been enabled for the System Administrator; similarly, it should be enabled for all profiles of various users who are intended to access Cymmetri.

For enabling the connected app administrator needs to go to Setup->Manage Users-> Profiles, then select the profile for which the connected app needs to be enabled

Once the profile is selected click on Edit button and look for Connected App Access section.

In the Connected App Access section look for the custom app you created(Cymmetri in this case) and click the checkbox to enable the access.

Once all the configurations on Salesforce end are done, the administrator must proceed with the configuration on the Cymmetri side. To achieve this, the administrator needs to go to Authentication->Identity Provider->External IDP. Here you may either configure the already created salesforce-idp instance or +Add New

In either cases a screen opens where you need to provide the below mentioned details

Name: salesforce-idp
IDP Type: Salesforce
Entity ID: Need to mention the EntityID from the metadata file downloaded from Salesforce
SSO Service URL: Need to mention the SingleSignonService url from the metadata file downloaded from Salesforce
Destination: https://<hostname>/spsamlsrvc/samlSP/SingleSignOn
Protocol Binding: HTTP Post (can also be set to HTTP Redirect if it is set so in Salesforce)
Name ID Policy:
- Policy: Unspecified(This may change based on what is configured in Salesforce)
- Value: Login(This may change based on what is configured in Salesforce)
Certificate: Certificate downloaded from Salesforce
Logout Request URL: Need to mention the SingleLogoutService url from the metadata file downloaded from Salesforce
Logout Protocol Binding:HTTP Post (can also be set to HTTP Redirect if it is set so in Salesforce)
Service Provider Id: cymmetri (Need to the select the configured Service Provider as shown above)

Once the external IDP is configured next we need to configure Authentication Rules as explained here and as shown below. Conditions mentioned here may vary based on actual scenario in which the IDP needs to be applicable.

Now the user can login into Cymmetri using Salesforce. The user needs to provide his/her username and click on Next.

The user is then redirected to Salesforce login page where the user needs to enter their Salesforce credentials and click on Log in

Once the salesforce credentials are successfully validated the user is redirected to Cymmetri home page.

Service Provider

Configuring Cymmetri as a Service Provider

Administrator needs to go to Authentication->Service Provider

Then click on +Add New button, On the screen that appears most of the data is prefilled. Yet if the administrator needs the data can be changed as per need. Once done click on Save. The prepopulated data appears as below:

Once saved the Service Provider(Cymmetri) appears as below:

The service provider is created at this step, download the metadata(xml file) of the same.

Authentication Rules

Within Cymmetri, the authentication process is highly customizable through the definition of authentication rules. While the platform provides a default authentication rule, administrators have the ability to define custom authentication rules that align with the specific business needs and the variety of identity providers at their disposal.

For instance, let's consider a scenario where an organization has distinct user types, such as regular employees, contractors, and administrators. The administrators might require to authenticate employees with Active Directory as the identity provider and use Cymmetri's own authentication engine to verify the identity of vendors and contractors. With Cymmetri's flexibility, administrators can create authentication rules that cater to these varying requirements, ensuring a tailored and secure authentication experience based on user roles and organizational needs.

Admins can find authentication rules in Authentication tab in Cymmetri.

To create a new authentication rule, admin must simply click on the "Add New" button on the top right corner of the page.

The admin must fill in the following details

The name of the rule
Identity provider radio button ( Enable for External IDP or Disable for Internal IDP)
Identity provider
Description of the rule
Active Radio Button

Conditions

The administrator has the capability to establish rules based on conditions like: Department, designation, User Type, country, and Login Pattern.

Subsequently, the administrator defines regular expressions for conditions, specifying whether they should be equal to, not equal to, and assigns corresponding values.

Cymmetri facilitates the creation of multiple conditions for an authentication rule and provides the option to group these conditions using AND or OR logic.

In the image presented above, an exemplar authentication rule is showcased. This rule is structured to authenticate a user in Cymmetri through Active Directory if two conditions are met: the user's department must be equal to "Compliance," and the user type should be "Employee."

Similarly If you wish to set the Identity provider for users having email address ending with "@cymmetri.com" then you may select condition as LoginPattern > Regular Expression and its value as (.)*(@cymmetri.com)+$; and save the details.

This demonstrates how authentication rules can be precisely configured to suit specific criteria and streamline the authentication process based on defined conditions.

Password Policy

What is a Password Policy?

A password policy is a set of rules and requirements established by an organization or system to govern how users create and manage their passwords.

The purpose of a password policy is to enhance security by promoting the use of strong, unique passwords and minimizing the risk of unauthorized access.

In Cymmetri, only the admin can create a password policy bby navigating to the authentication section and then in password policy.

Upon landing the user can view a default Cymmetri password policy which cant be deleted or deactivated.

To create a new password policy, the admin clicks on the add new button on the top right corner of the page.

The user has to fill in the password policy form with the below details

Policy Name - Name of the policy
Description
Conditional attribute type - Default - User (Non modifiable)
Conditional attribute Name - Default - User Type (Non modifiable)
Conditional attribute value - ( Consultant, Employee, Vendor)

After saving the detail, a new password policy is created. The next step is to define the password policy. This is done by clicking on the edit button in front of the record.

The admin can define the composition of the password. By rejecting

Password equals Password
Password which equals to LoginID
Password which equals to first or Last Name
Blacklisted Password

The admin can also establish the following parameters

Numeric characters minimum count
Password Length
Special characters count
Password History versions
Alpha characters
Uppercase characters
Lowercase characters
Characters not allowed in the password

In the "change" subsection the admin can also define:

Password expiration days
Password expiration warning from (no of days)
Whether to change password on reset

Blacklisted Password

The administrator also has the capability to set prohibited passwords, preventing users from using those specific passwords.

Global Auth Policy

The Global Auth Policy allows to configure various user login parameters as shown below:

Auth Failed Count: The Auth Failed Count parameter signifies after how many failed login attempts will the user account be locked.

Unlock after Minutes: The Unlock after Minutes parameter signifies after how many minutes will a locked account be automatically unlocked.

Token Expiry Minutes: The Token Expiry Minutes parameter signifies after how many minutes will the session token expire.

Refresh Token Expiry Minutes: The Refresh Token Expiry Minutes parameter signifies after how many minutes will the refresh token expire.

User Session

Cymmetri allows users to have multiple sessions simulatenously i.e. they can login simulatenously from various locations and keep all the sessions alive. It also provides control to the user to revoke any specific or all the sessions

Adaptive

Adaptive authentication is an advanced security measure that assesses various factors and context elements in real-time to determine the level of risk associated with a user's access attempt.

Based on this risk assessment, the authentication system can dynamically adapt its level of scrutiny and request additional verification steps if needed. This approach enhances security while minimizing disruption for legitimate users.

In Cymmetri there are various adaptive checks that the admin can enable for additional factor of authentication.

Device Trust Check - If enabled, Cymmetri will check if the device being used to perform action on the Cymmetri portal, has been trusted by the user
User Behavior - Cymmetri determines whether the behavior of user matches with the known behavior pattern of the user over time
Blacklisted IP - Maintains a blacklist of IP addresses that are known to be sources of unauthorized access, hacking attempts, or other malicious activities
Blacklisted Location - Cymmetri maintains a list of locations from which the administrator wishes to restrict access of the portal
Short Lived Domain - Cymmetri checks the email address domain of the user with a database of known providers of short-term or disposable email addresses
Impossible travel scenario - Tracks the change in location of user attempting an action over a short period of time and flagging if, system deems the pattern to be impossible.

The admin can enable these checks as per the business use case

To navigate to the adaptive settings page, click on the "Go to settings" button on the top right corner of the page.

IP Address Checks

Administrators can include an IP address in the blacklist by following these steps:

Enable the "IP address Check" radio button at the top of the page, input the IP address into the "Blacklisted IP address" field, and press enter. The specified IP will be added to the list. To synchronize the list with the database, click the "Sync Now" button.

You can select additional actions when module detects an anomaly. They are the following:

Ask additional MFA and notify - If an MFA rule has been established and adaptive authentication is activated for it in the MFA section, when a user attempts to log in with a blacklisted IP address, the user will be prompted for additional factor(s) for authentication as defined by the rule. Additionally, the user will receive email notifications regarding the login activity.

Only Notify - This option solely sends a notification to the user about the login activity.
Block user and notify - This option not only blocks the user upon a login attempt with a blacklisted IP but also notifies the user on their registered email ID.

Device Trust

Define how Cymmetri determines if a device is trusted for the user and allows to define behavior of authentication in Cymmetri, in case of untrusted device

The admin can define

No of successful authentication attempts
Number of devices per user
Number of days
Additional action when module detects anomaly

Location based checks

Organizations can maintain a list of blacklisted locations as part of their adaptive authentication strategy to enhance security measures and mitigate potential risks

The admin can select the blacklisted location on this page. Also additional actions on these checks can be selected.

Impossible Travel Scenario

Track the changes of location from which the user attempts to perform actions on the portal over a short period of time and flags an action attempt

The admin can configure the:

Check Windows(in hrs)
Average Distance (in Km)

Short lived Domain Checks

Checks the .email address domain of the user with a database of known providers of short-time or disposable email addresses

The admin can Sync the database where the domains are stored and updated

User behavior checks

Cymmetri determines whether the behavior of user matches with the known behavior pattern of the user over time

The admin can select the required checks to verify the consumer behavior:

Unusual time of Login
Unusual number of Login failures
Unusual keystrokes pattern

The admin can enable, configure and save these adaptive checks individually as and when required.

Attribute Setting

In Cymmetri, the Attribute Setting is a tool for user attribute management.

It provides administrators with granular control over attribute visibility during user creation or updation processes. This feature empowers administrators to enable or disable both predefined and custom attributes effortlessly.

When an attribute is disabled, that associated field doesn't appear anywhere in the user creation or updation pages, streamlining the user management experience.

Logs

Import History

The "Import History" tab in Cymmetri provides a comprehensive record of all data imports, ensuring transparency and accountability in managing user and system information. This feature is designed to offer administrators insights into the history of data imports, facilitating effective tracking and auditing.

To check the import history in Cymmetri, go to the "Import History" tab within the Logs section. This area keeps track of all bulk import events, including imports for user and application assignments.

In this section, administrators can find a detailed history of import events, including:

File Name: The name of the file that was imported.
Status: The status of the import activity, indicating whether it was successful or if there were any issues.
Import Type: Specifies the type of import, such as user or application assignment import.
Created By: Shows who initiated or performed the import.
Created At: Indicates the timestamp of when the import occurred.

For a closer look at the import history, administrators can click on the eye icon next to a specific record. This detailed view provides insights into the imported record statuses, including:

Created Successfully in Cymmetri: Indicates records that were successfully created within the Cymmetri system during the import.

Duplicated in the System While Importing: Highlights instances where records already existed in the system, preventing duplication during the import process.

Error Occurrence During Import with Remarks: Flags any errors that occurred during the import, accompanied by remarks detailing the nature of the issue.

Scheduler History

In Cymmetri the "Scheduler History" feature plays a crucial role in maintaining visibility and control over scheduled tasks and operations. This functionality is designed to offer administrators insights into the history of scheduled events, providing transparency, accountability, and efficient management of routine processes.

In the "Scheduler History" tab, accessible within the Logs section of Cymmetri, administrators can delve into the details of scheduled tasks, gaining insights into various aspects of the scheduler's operation. The information presented includes:

Event of the Scheduler: Specifies the type of scheduler event that took place.

Event of the Scheduler: Specifies the type of scheduler event that took place.
Description: Provides a brief description of the scheduled task or operation.
Operation Performed on the Scheduled Period: Outlines the specific action executed during the scheduled period.
Planned At: Indicates when the scheduler was initially planned or scheduled.
Sub Event: Offers details about any sub-events associated with the scheduler operation.
Executed At: Specifies the timestamp when the scheduler was executed.
Execution Status: Highlights the status of the scheduler execution, indicating whether it was successful or encountered issues.
Remarks (If Any): Includes any additional remarks or notes related to the scheduler operation, offering insights into the execution process.

Lifecycle Management

Application Management

Getting Started

Reconciliation How to

Rules

Workflow Management

Single Sign On

SSO Configuration

OpenID Connect Based SSO

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 Sign On 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 authorization 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 Authorization 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 Authorization 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 Platform: Cymmetri 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 (Authorization Server): Since Cymmetri acts as an Identity platform, it holds the capability to ensure that user session is valid, the user is authorized to access the managed application, among other authorization decisions, it plays the role of Authorization server in the OpenID Connect 1.0 process.
2. User Management Module (Resource server): Since Cymmetri 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 Sign On, 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 Authorization 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 Token and ID Token by using the authorization 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 Cymmetri , 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 Authorization provider (Cymmetri).
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 Cymmetri 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 Cymmetri is a response for the request raised by it for Single SignOn and to prevent replay attacks.
Access Token: Access token is generated by Cymmetri 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 Cymmetri 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.
Authorization Code: This is a string generated by Cymmetri for the purpose of server-to-server communication between the Relying party (managed application) and the Authorization provider (Cymmetri). 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 authorizing access to REST APIs by verifying that the client making the calls has the requisite access.

Commonly Used OpenID Connect 1.0 flows

Authorization 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.

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.

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 Authorization Code Grant Type

Understanding the Authorization 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 Authorization 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.

SAML 2.0 Based SSO

Note: 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 Sign On 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 platform acts as the Identity Provider (IdP) and the managed application that the end-user wishes to access through Single Sign On acts as the Service Provider (SP).

SAML 2.0 bindings

The mechanisms within the SAML 2.0 protocol used for sharing Single Sign On 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 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.

SAML 2.0 Request-Response Cycle

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)

To start the configuration of the managed application for SAML 2.0 based SignOn mechanism, we must identify the flow supported by the managed application.

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

Service Provider Initiated Flow (SP Initiated Flow)

The SAML 2.0 Service Provider Initiated flow indicates that the Service Provider (in our case, the managed application which the end-user wishes to access via Single Sign On) has started the SAML 2.0 Single Sign On process by sending a SAML 2.0 request XML to the Cymmetri platform. This is achieved by the user landing on the Single Sign On URL of the managed application.

In practice, however, since the user is typically on the Cymmetri 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 expected Protocol Binding, and the Issuer of the Request.
A redirect is made to the page handling Single Sign On requests on the Cymmetri platform (<baseurl-of-cymmetri-tenant/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 authorized 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 platform generates a SAML response XML body and send it as GET request query parameter (if the protocol binding in the SAML request is HTTP Redirect) or as a POST request body (if the protocol binding 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 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.

Note: 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 Sign On configuration page.

Service Provider(SP) Initiated Flow Configuration

The configuration parameters mentioned below are required to configure an application for Single Sign On using the Service Provider Initiated flow in the Cymmetri platform.

Prerequisites from the Managed Application

Entity ID/ 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 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.

Let us see an example demonstrating SP Initiated flow. We will be using a Service Now Instance for this example.

Initially, we include a SAML service provider from the Single Sign-On section under Service Providers by selecting the "Add New" button located at the top right corner of the page.

The Admin will be displayed the below SAML SSO configuration page in Cymmetri

Now go back to Service Now instance and Navigate to Multi-Provider SSO > Identity Providers. Choose any existing IdP and click the Generate Metadata button. The integration automatically generates the instance's SP metadata from the system property settings.

Let us come back to the SAML 2.0 settings for our managed application in Cymmetri platform and start entering the fields one by one.

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

Since the metadata downloaded from ServiceNow 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 only 1 supported NameID format

emailAddress: This indicates to the managed application, that the Identity Provider (Cymmetri Platform) will be sending the end-user’s email address, and that the managed application must handle it accordingly.

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

NameID Formats:

unspecified: This is a generic and default selection of NameID format, typically this would mean that the Cymmetri 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.
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.

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 metadata.xml from the Service Now application.

We use the entityID from the downloaded metadata as the Entity ID

Please note that the Entity ID field is how the Cymmetri platform identifies the managed application from the SAML Request sent by the managed application. Please ensure that the Entity ID 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://dev190728.service-now.com/navpage.do"

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

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

Now go back to the main page and Download the Service provider meta data by clicking on the ellipsis in front of the record.

The metadata you've downloaded will appear in a format similar to this.

Let us return back to Service Now application for completing the configuration on the Service provider side.

Note:

Before starting the IDP Configuration the Multi Provider SSO Plugin needs to be enabled. Steps for the same are provided here: https://docs.servicenow.com/bundle/vancouver-platform-security/page/integrate/single-sign-on/task/t_ActivateMultipleProviderSSO.html

Also the plugin is activated, we need to Configure Multi-Provider SSO properties, Steps for the same are provided here: https://docs.servicenow.com/bundle/vancouver-platform-security/page/integrate/single-sign-on/task/t_ConfigureMultiProviderSSOProps.html

For successfully enable SSO properties you might have to configure an account recovery user, Steps for the same are provided here: https://docs.servicenow.com/bundle/vancouver-platform-security/page/integrate/single-sign-on/concept/config-acr.html

Once the above 3 steps are successfully completed we can create a new IDP

Create a new IDP

Click on the New button to create a new IDP

Then select SAML

Then upload the metadata from the file downloaded in a previous step. and Hit Import button to store the Identity provider metadata in the application.

Once imported provide the Signing/ Encryption Key Alias and Signing/ Encryption Key Password as saml2sp and in the Advanced Tab tick the CreateAuthnContextClass checkbox. The Signing/ Encryption Key Alias and Signing/ Encryption Key Password are used for encryption of data and the CreateAuthnContextClass is used to tell the IDP that Service Now requires that they present a specific login mechanism such as form, Kerberos etc.

Note: Also make sure both the logout urls present here are removed temporarily for testing purposes, else you would logout completely from ServiceNow

Then enter the instance url in the SignOn configuration of the managed application on the Cymmetri portal.

Click the “Save” button.

Next Create a New User in Service Now. Go to Organization->Users->New and provide the credentials of the user logged into Cymmetri as show below and Submit:

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.

Then to activate the externa IDP in Service Now we need to test the connection on the Service Now side by clicking on the Test Connection button.

Once successfully tested you should see the below screen with successful test results. Click on the Activate button to activate the IDP.

Once activated Click on the Set as Auto Redirect IdP link to automatically redirect to IDP when using a SP Initiated process

Once it is enabled we can come to the currently logged in user's My Workspace-> My Access page and click on the Service Now application tile

We will now be redirected to the ServiceNow home page using the logged in users crendentials as shown below:

Identity Provider Initiated Flow (IdP Initiated Flow)

The SAML 2.0 Identity Provider Initiated flow indicates that the Identity Provider (in our case, the Cymmetri 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 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 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 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.

Identity Provider(IdP) Initiated Flow Configuration

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

Entity ID/ Request Issuer: This is the entity id/ 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.

Note: 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.

Initially, we include a SAML service provider from the Single Sign-On section under Service Providers by selecting the "Add New" button located at the top right corner of the page.

The Admin will be displayed the below SAML SSO configuration page in Cymmetri

Let us start entering the fields one by one.

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

All the remaining steps for configuring IdP Initiated SAML 2.0 flow are same as shown above in the SP Initiated flow.

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 currently logged in user's My Workspace-> My Access page and click on the Service Now application tile

We will now be redirected to the ServiceNow home page using the logged in users crendentials as shown below:

Identity Provider Initiated Flow (IdP Initiated Flow)

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 entity id/request issuer field in the Cymmetri Identity platform for the managed application.

Fix: Verify and change the entity id/ 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.

SAML Attribute Mapper

A SAML Attribute Mapper is a component or feature in a Single Sign-On (SSO) or identity federation system that helps map user attributes between different identity providers (IdPs) and service providers (SPs) during the SAML (Security Assertion Markup Language) authentication process.

Here's how it works:

Authentication: When a user tries to access a service or application that requires authentication, they are redirected to an identity provider (IdP) for authentication. The IdP verifies the user's identity and generates a SAML assertion containing information about the user.
SAML Assertion: The SAML assertion typically contains various attributes about the user, such as their username, email address, roles, or other user-related information. These attributes are represented as name-value pairs.
Attribute Mapping: Before the SAML assertion is sent to the service provider (SP), which is the application or service the user is trying to access, there may be a need to map or transform these attributes. This is where the SAML Attribute Mapper comes into play.
- Attribute Transformation: Sometimes, the IdP may use different attribute names or formats than what the SP expects. The SAML Attribute Mapper can transform the attributes in the SAML assertion to match the expectations of the SP.
- Filtering: The mapper can also be used to filter or select specific attributes from the SAML assertion. For example, if the IdP provides a wide range of attributes, but the SP only needs a subset of them, the mapper can be configured to include only the required attributes in the assertion sent to the SP.
- Value Mapping: It can map attribute values as well. For instance, if the IdP uses "userType=employee" and the SP expects "role=employee," the mapper can perform this value mapping.
Forwarding to SP: Once the attributes in the SAML assertion are mapped or transformed as necessary, the SAML assertion is forwarded to the service provider. The SP can then use these attributes for authorization and access control decisions.

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 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.

Service Now can use this data for auto provisioning of users via jit provisioning provided Auto Provisioning User is enabled under the User Provisioning tab in the Identity Provider Configuration page.

Samples

SAML 2.0 Sample Request

SAML 2.0 Sample Response

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
                 Destination="https://dev165684.service-now.com/navpage.do"
                 ID="_6db464f3-b783-4834-98ea-6ed1681dd2cd"
                 IssueInstant="2023-09-26T10:19:01.472Z"
                 Version="2.0"
                 >
    <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">ccaa</saml2:Issuer>
    <saml2p:Status>
        <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </saml2p:Status>
    <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
                     xmlns:xs="http://www.w3.org/2001/XMLSchema"
                     ID="_e4baa225-cd79-4ac2-93b3-0a5ab7ef2f87"
                     IssueInstant="2023-09-26T10:19:01.472Z"
                     Version="2.0"
                     >
        <saml2:Issuer>ccaa</saml2:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
                <ds:Reference URI="#_e4baa225-cd79-4ac2-93b3-0a5ab7ef2f87">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                            <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
                                                    PrefixList="xs"
                                                    />
                        </ds:Transform>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                    <ds:DigestValue>4BaEkbuyzytz0XkXo19cBeLjGnYrTOvPhxfv3NWyidc=</ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>vRw1lhio5G38L/inuAp9l9yjekbCCM4BduLykL7vg4wijlHmbrSMiNJNuqOu8vO79Aqruj6GBafGRD6Slqrco5vScsWbfH5LiHz5UejAh2sGsqbQHapYFPlZJ6ErauwFxbzGN7od5CYlZUgDPUdO1dF2jiwoYeqhs+aQOISsyoq9pcQ2yl35wmaUy6C388a+m54OzygQhwsQdxEeA1OqLDtAw3ulTxbKsjRw1hAa7zv4JKKO10HirrWwWXDe3dSsh2Z3um0sF6TxWjV5wKXKflXz1alNPcNBONTjTWOfwKD/a+agZITQ8jGJAo6vZXfF3bI7N0uo3dWF3ogK2jzpjg==</ds:SignatureValue>
        </ds:Signature>
        <saml2:Subject>
            <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">Ak@mail.com</saml2:NameID>
            <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml2:SubjectConfirmationData NotOnOrAfter="2023-09-26T18:19:01.472Z"
                                               Recipient="https://dev165684.service-now.com/navpage.do"
                                               />
            </saml2:SubjectConfirmation>
        </saml2:Subject>
        <saml2:Conditions NotBefore="2023-09-26T10:16:01.472Z"
                          NotOnOrAfter="2023-09-26T10:22:01.472Z"
                          >
            <saml2:AudienceRestriction>
                <saml2:Audience>https://dev165684.service-now.com</saml2:Audience>
            </saml2:AudienceRestriction>
        </saml2:Conditions>
        <saml2:AuthnStatement AuthnInstant="2023-09-26T10:19:01.472Z"
                              SessionIndex="_e4baa225-cd79-4ac2-93b3-0a5ab7ef2f87"
                              >
            <saml2:AuthnContext>
                <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml2:AuthnContextClassRef>
            </saml2:AuthnContext>
        </saml2:AuthnStatement>
        <saml2:AttributeStatement>
            <saml2:Attribute Name="User Name"
                             NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
                             >
                <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                      xsi:type="xs:string"
                                      >Ak@123</saml2:AttributeValue>
            </saml2:Attribute>
            <saml2:Attribute Name="email"
                             NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
                             >
                <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                      xsi:type="xs:string"
                                      >Ak@mail.com</saml2:AttributeValue>
            </saml2:Attribute>
            <saml2:Attribute Name="firstName"
                             NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
                             >
                <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                      xsi:type="xs:string"
                                      >Akash</saml2:AttributeValue>
            </saml2:Attribute>
            <saml2:Attribute Name="lastName"
                             NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
                             >
                <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                      xsi:type="xs:string"
                                      >Patil</saml2:AttributeValue>
            </saml2:Attribute>
        </saml2:AttributeStatement>
    </saml2:Assertion>
</saml2p:Response>

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

}

3.0.0

Getting Started

What is Cymmetri?

What is Cymmetri?

Release Notes

Version: 3.0.0

New Features

General Features

Provisioning

Bulk Import

Workflow

MFA

Risk Engine

Password Filter

SSO

Webhooks

PAM

Starting your Cymmetri Trial

Admin Dashboard

Accessing Cymmetri

Supported Web Browsers

DESKTOP:

MOBILE:

Cymmetri Error Codes

Help

Key Features of the Help Page:

Personalization

General Configuration

On Behalf

Time Based

Email Config

Suspend Config

Workflow Preference Config

Reset Password OTP Config

User Decommission Config

Syslog Configuration

Webhooks Configuration

Application Request Config

Threshold Delete Config

Admins

Administrators

Organization Administrator

Domain Administrator

Application Administrator

Report Administrator

Help Desk Administrator

Read Only Administrator

PAM Write Access

PAM Read Access

PAM Report Access

Adding a New Admin

All Admins

Masters in Cymmetri

Global Masters

Types of Global Masters:

Adding a new Master

Zone Masters

Personalize Notification Templates

Tenant Branding

Configuring your tenant branding

Custom Attributes

Configuring Custom Attributes

Identity Hub

Managing Users and Groups

User Management

User Management

User Information Display

Contextual Actions

User Detail

User Profile Overview

Profile Picture

User's Status

Login ID

Email ID

Mobile Number

User Info Page

Basic Information

Contact Information

Organization Information

Custom Attributes