1 of 8

Getting Started

Introduction to Application Management

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

Adding Applications

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

Single Sign On

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

Managing the Application Sign On Policy

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

Provisioning

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

Reconciliation

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

Assigning Application

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

Adding Applications to be managed by Cymmetri

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

Applications menu can be accessed as mentioned below:

Identity Hub

Login as either an Organization Administrator, Domain Administrator, or Application Administrator.
Click on the Identity Hub icon on the left side bar.
Click on the Applications text on the slide out bar.

Understanding the applications supported by Cymmetri

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

Pre-configured Applications These are the applications that have already been configured by the Cymmetri platform for provisioning on cloud or on-premises.
Custom Applications for Provisioning These are the applications that you wish to manage through Cymmetri and support the generic connectors that the Cymmetri platform provides.
Custom Applications for Single SignOn only When you need to add an application for the sole purpose of enabling Single Sign-On (SSO), Cymmetri offers the capability to add a custom application that can be configured for SSO using the supported mechanisms.

Adding Application

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

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

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

And also support for other standard categories of applications as shown below:

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

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

Conclusion

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

Assigning Applications to End Users

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

Application Assignment

There are three ways in which applications can be assigned to users:

Admin may assign an application directly to a user.
Admin may map an application to a group; and the user is added to the group or is already part of the group.
End User may request an application and is granted access to the application.
Bulk Assignment of application to a set of users

Let us understand the flow for each of the above mentioned scenarios:

1. Admin assigns an application directly to the end user

Users with admin roles such as Organization Admin, Domain Admin, or Application Admin on the Cymmetri platform can assign managed applications to end-users .

First, we need to add the application to the Cymmetri platform
Next, we move to configure the application to assign it to an end user.
Click on the application tile to configure it.

The flow for assignment goes as follows -

Description:

Admin clicks on the application tile, and starts the configuration.
Click on the Assignments tab on the left hand side menu.
Click on the “Assign New” button on the Users menu.
Here we need to decide whether we want to provide a Lifetime Access or a Time Based Access
1. Lifetime Access: Users have access to the application without any time restrictions.
2. Time Based Access: Users have access to the application only for the specified range of time. We need to provide a Start Date & Time and an End Date & Time for Time Based Access.
Now click on Save to register a request for the application assignment. If no Workflow is configured for the said application the application is immediately assigned to the user.
If a workflow for application provisioning is configured then the workflow is been initiated.
The workflow approver will then receive a request to approve the user assignment in their inbox.
Now the approver may approve or reject the user assignment
The approver may change the start and end date, if required; refer to the dynamic form attributes passed during the application assignment.
To continue the flow click on Accept button.
Now the next level of approver will be able to see the previous levels of approval, and similar to the previous level of approval, the approver may change the start and end date, if required; refer to the dynamic form attributes passed during the application assignment.
Click “Accept” to proceed.
After the last level approver has also approved the assignment, the backend processes will run the application provisioning flow.
Once the user has been provisioned in the application, they will be able to see it in their list of applications.

2. Admin assigns an application directly to a group

Users with admin roles, such as Organization Admin, Domain Admin, or Application Admin, in a Cymmetri Identity platform deployment, will have the ability to assign entire groups of users to managed applications.

First, we need to add the application to the Cymmetri platform
Next, we move to configure the application to assign it to a group.
Click on the application tile to configure it.

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

Description:

Click on the application tile, and start the configuration.
Click on the Assignments tab on the left hand side menu.

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

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

5. Checking for the users who belong to the group, we can see that the application has been assigned.

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

3. User requests for an application

Users on the Cymmetri platform can request access to a managed applications as a Self-Service feature.

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

Description:

Visit the “My Workspace” menu.
Click on the “My Access” left-hand side menu.

3. Now Click on the “+ Request” button on the top-right button.

Here we need to decide whether we want to provide a Lifetime Access or a Time Based Access
1. Lifetime Access: Users have access to the application without any time restrictions.
2. Time Based Access: Users have access to the application only for the specified range of time. We need to provide a Start Date & Time and an End Date & Time for Time Based Access.
Now click on Save to register a request for the application assignment. If no Workflow is configured for the said application the application is immediately assigned to the user.
If a workflow for application provisioning is configured then the workflow is been initiated.
The workflow approver will then receive a request to approve the user assignment in their inbox.
Now the approver may approve or reject the user assignment
The approver may change the start and end date, if required; refer to the dynamic form attributes passed during the application assignment.
To continue the flow click on Accept button.
Now the next level of approver will be able to see the previous levels of approval, and similar to the previous level of approval, the approver may change the start and end date, if required; refer to the dynamic form attributes passed during the application assignment.
Click “Accept” to proceed.
After the last level approver has also approved the assignment, the backend processes will run the application provisioning flow.
Once the user has been provisioned in the application, they will be able to see it in their list of applications.

4. Bulk Assignment of application to a set of users

An administrator can bulk assign an application to a set of users. This an be achieved by uploading a .csv file which contains user information like., loginId, appUserId and roleId. For bulk assigning applications to users in Cymmetri platform administrator needs to

Click on Identity Hub > Applications menu and then click on the Applications Assignments button.

A screen pops up that lets you select the csv file you want to upload that contains the list of users to whom the application needs to be assigned, 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.
Once you have ensured the parameters are correct next select the application that needs to be assigned and click on Next button.

Match the Column names from the CSV file with the corresponding attributes using this File Info dialog box and click on the Import button.

Note: The "Link Application" check box is available to provision the user in the target application

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

If any workflow is configured on the application provisioning then the corresponding workflow is triggered after the successful completeion of assignment as shown below:

Application Detail

The Application Detail Page provides comprehensive management features for applications within the system. It includes various sub-pages for configuring assignments, sign-on protocols, policies, provisioning settings, roles, and more. Below we outline the functionalities and configurations available on each sub-page.

Assignments

This page allows administrators to assign users and groups to an application. Users or group members can access the application if it is configured for Single Sign-On (SSO) or get provisioned in the application if it is a provisioning application.

Features:
- Assign users and groups to the application.
- View and manage existing assignments.

SignOn

Configures the application for sign-on using various protocols.

Supported Protocols:
- SAML: Configure SAML-based single sign-on.
- OpenID: Set up OpenID Connect for authentication.
- Reverse Proxy: Configure reverse proxy settings for sign-on.
- API SSO: Set up API-based single sign-on.
Features:
- Protocol selection and configuration.
- Test and validate sign-on settings.
- Manage sign-on settings for different environments.

SignOn Policy

Configure Multi-Factor Authentication (MFA) for the application’s SSO settings.

Features:
- Configure MFA prompts and policies.
- Manage MFA settings to ensure secure access.

Provisioning

Configure application provisioning with various settings organized into tabs.

Tabs:
- User Configuration: Define application attributes and settings for provisioning.
- Server Configuration: Set up connector server parameters.
- Operations: View provisioning operations supported
- Hook Configurations: Configure hooks for triggering provisioning actions.
Features:
- Manage and configure provisioning details.
- View and edit provisioning settings.
- Monitor provisioning operations.

Roles

Create and manage application roles and import roles from CSV files.

Features:
- Create new roles.
- Import roles via CSV for bulk role creation.
- Manage and edit existing roles.
- Ensure roles are correctly provisioned in target applications.

Policy Map

Configure mapping between the provisioning source application and Cymmetri user fields.

Features:
- Define and manage field mappings for data synchronization.
- View data mappings for User Pull Reconciliation.
- Ensure accurate data exchange between systems.

Settings

Configure general settings for the application. This section allows you to modify application label and description. You may also configure other settings as shown below:

Application Risk Level:

This section lets you set application's risk which enables for identifying overall risks for users. The Risk level can be set to High, Medium, Low and Unknown

Visibility settings:

Administrator may configure visibility settings as shown below

Show to User: This setting when enabled lets the user see an application assigned to them.
User can request: This setting when enabled lets the user to request an application which is not assigned to the user.

Role settings:

Administrator may configure various role settings as shown below:

Multiple role assignments: which allows a user to have multiple roles in the said application and
Mandatory roles: This setting mandates that when the application is assigned atleast one role is assigned to the user
Add notes for end users and administrators.

Policy Attribute

This page lets you configure all the attributes from the provisioning source whose data needs to be synced on either sides.

Reconciliation

Configure reconciliation settings for data synchronization.

Features:
- Set up pull reconciliations to retrieve data from the source application.
- Configure push reconciliations to update data in the source application.
- Manage reconciliation schedules and tasks.

Forms

Configure dynamic forms used in workflows for additional data collection.

Features:
- Create and manage dynamic forms.
- Configure forms to collect data during workflow processes.
- View and edit form data as required by administrators and users

Tags & Meta

Manage tags and meta information for applications.

Features:
- Create and assign tags for categorization and search.
- Add and manage meta information for various purposes.
- Use tags and meta data to enhance application organization, search and categorization

360 Degree Recon

Description: Provides a comprehensive reconciliation view for data synchronization across the system.
Features:
- View detailed reconciliation data and statuses.
- Analyze and resolve reconciliation issues.

Dynamic Forms

Dynamic Forms enable administrators to request additional fields from either administrators or end-users when assigning applications. These additional user fields are then collected and used for provisioning the user into the managed application.

Creating a dynamic form:

For creating a dynamic form the administrator needs to configure the managed application. For e.g. Identity Hub->Applications->Service Now(Application may change )->Forms

Load the default form by clicking on the “Load Sample Data” button

Edit the default form in the JSON Schema section, In the JSON Schema section the administrator can define the form structure with the type of element, and its various properties like type, title, default value etc., a preview of the form is shown on the right hand side.

Let us create a simple form that can capture

“Preferred Username” [text field] and
“Request Additional Modules” [Radio] with two options “Administrator” and “Read Only”.

The code below shows how to create a simple form described above:

{ 
  "type": "object", 
  "required": [ 
    "preferredName" 
  ], 
  "properties": { 
    "preferredName": { 
    "type": "string", 
    "title": "Preferred Username", 
    "default": "" 
  }, 
  "additionalModules": { 
    "type": "string", 
    "title": "Additional Modules", 
    "enum": [ 
      "admin", 
      "readonly" 
    ], 
    "enumNames": [
       "Administrator",
       "Read-Only" 
    ], 
    "default": "" 
    } 
  }
}

The UI Schema is like a set of json properties that are used to configure how the form should look and behave. It lets you tweak things like the length of a text box or whether a choice should be shown as radio buttons or checkboxes. In the example code, we're using the UI Schema to make the "preferredName" field have a placeholder and also set a maximum length. For "additionalModules," we're using widget property to make it show up as a radio button.

{
  "preferredName": {
    "placeholder": "Enter preferred name",
    "maxLength":5
  },
  "additionalModules": {
    "ui:widget": "radio"
  }
}

The Preview Form Data displays how the data entered in the UI will be gathered and shows the structure in which the data will be sent to the API.

The preview of the form looks as below after making the changes:

Once configured the administrator can Click on the Save button.

Once saved a confirm box appears to enable the form; the administrator needs to click on the Confirm button in the popup to enable the form for the application.

Form Options

There are four options in that can be configured after enabling forms in Cymmetri

Form View: If enabled, the user has the option to see the application request form within the My Access section.
Form Edit: If enabled, the user has the option to edit the application request form within the My Access section, this will make changes in the respective fields in the target application.
Role Assignment: If activated, the user will be displayed the request form for applications that are already assigned to them when attempting to request additional roles.
Role Unassignment: If activated, the user will be displayed the form for applications when he/she is raising requests for role removal.

Configuring Connector Server

Connectors can be deployed in two ways:

Local connectors are deployed to a Cymmetri instance. This is the usual way how connectors are used. The connector is executed inside a Cymmetri instance, has the same lifecycle (start/stop), etc. Cymmetri can detect local connectors automatically and overall the connector management is easier.
Remote connectors are executed in a different process or on a different node than Cymmetri instance. Remote connectors are deployed to a connector server. There may be need to use a remote connector e.g. to access a file on a remote system (e.g. in case of CSV connector) or because of platform incompatibilities (e.g. .NET connectors)

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

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

Connector servers are available for both Java and .NET.

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

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

Java Connector Server

Installing a Java Connector Server

Minimum Requirements:

Java 1.6 or later for 1.4.X.Y / Java 1.8 for 1.5.X.Y
Refer to your Java connectors to determine if there are any additional requirements

Create your execution environment

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

Test your execution environment

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

Linux / MacOS: ./bin/ConnectorServer.sh
Windows: \bin\ConnectorServer.bat

You should see the following output:

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

Configure your Java connector server

Run the connector server with the setkey option as described below to set your desired key into your properties file
- Linux/ MacOS: ./bin/ConnectorServer.sh -setkey <key> -properties conf/ConnectorServer.properties
- Windows: bin\ConnectorServer.bat /setkey <key> /properties conf\ConnectorServer.properties
For all other properties (e.g. port), edit the conf/connectorserver.properties manually. The available properties are described in the connectorserver.properties file.

Running your Java connector server

Run the server by launching with the -run option:

Linux / MacOS: ./bin/ConnectorServer.sh -run -properties conf/ConnectorServer.properties
Windows: bin\ConnectorServer.bat /run -properties conf\ConnectorServer.properties

Installing Connectors on a Java Connector Server

To deploy a Java connector:

Copy the Java connector bundle jar file into the bundles directory in your Java connector server directory
If necessary, add to the classpath any 3rd party jars required by any Java connector
Restart the Java connector server

Using SSL to communicate with connector servers

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

Deploy an SSL certificate to the connector server's system.
Configure your connector server to provide SSL sockets.
Configure your application to communicate with the communicate with the connector server via SSL.

Configure your application to use SSL

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

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

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

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

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

.NET Connector Server

Installing a .NET Connector Server

Minimum Requirements:

Windows Server 2003 or 2008
.NET Framework 3.5 or higher
Refer to your .NET connector to determine if there are any additional requirements

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

Configuring the .NET Connector Server

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

ConnectorServer /setkey <newkey>

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

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

Additional Notes about configuration

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

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

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

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

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

Host name or IP address
Connector server port
Connector server key
Whether SSL is enabled

Changing Trace Settings

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

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

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

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

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

Running the .NET Connector Server

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

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

ConnectorServer /run

Installing Connectors on a .NET Connector Server

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

Running Multiple Connector Servers on the Same Machine

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

360 Degree Recon

The 360 Degree Recon is one of a type feature of Cymmetri that enables administrators to have a holistic view of user data.

The 360-degree reconciliation process in Cymmetri is designed to ensure that identity data across different systems is consistent and up-to-date. The reconciliation process involves comparing records from Cymmetri with the records in target systems (like Active Directory) and identifying discrepancies that need to be addressed.

The 360-degree reconciliation process in Cymmetri is crucial for maintaining data integrity across all connected systems. By regularly running reconciliation, organizations can ensure that their identity data is accurate.

Configuring 360 Degree Recon

The 360 degree recon can be configured for all the provisioning applications supported by Cymmetri. Here we will be seeing an example of 360 Degree Recon with Active Directory.

As the first step for configuring 360 Recon the administrator needs to configure a pull recon as explained .

Once the pull recon is configured the user next needs to go on the 360 Degree Recon page as shown below:

The 360-Degree Reconciliation page displays all the pull reconciliations configured for either users or groups. The administrator can select a configured reconciliation and run a 360-degree reconciliation for that specific pull.

Once the 360-degree reconciliation is started the administrator can then go to the History tab and view the results of the reconciliation on the reconciliation dashboard

Reconciliation Dashboard

The reconciliation dashboard provides an overview of the latest reconciliation run, including key metrics and visualizations to help administrators quickly identify and address issues.

Key Metrics:

Last Start Date: Indicates the start time of the most recent reconciliation run.
Last End Date: Indicates the end time of the most recent reconciliation run.
Total Processed Records: The total number of records processed during the reconciliation.
Records Pulled from Target App: The number of records pulled from the target application (e.g., Active Directory).
Present in Cymmetri only: Number of records that exist in Cymmetri but not in the target system.
Present in Target only: Number of records that exist in the target system but not in Cymmetri.
Accounts Overdue in the target: Number of accounts that are overdue in the target system but not reflected in Cymmetri.

Break Type Analysis

The break type analysis section uses a pie chart to categorize the types of breaks (discrepancies) identified during the reconciliation. In the example shown in the image, all breaks are categorized as "Present in Cymmetri only," indicating that certain records exist in Cymmetri but are missing from the target system.

Filter Options

Administrators can filter the results based on several criteria:

Login ID: Search for discrepancies related to specific user logins.
Break Type: Filter the results based on the type of break (e.g., "IDM exists, Target not exists").
Break Count Min/Max: Filter based on the minimum and maximum break counts.

Reconciliation Results Table

The results table provides detailed information on the discrepancies found during the reconciliation process.

Columns:

User Login: The login ID of the user in the Cymmetri IDM system.
Source Application Login: The corresponding login ID in the source application (e.g., Active Directory).
Application Login: The login ID in the application (if applicable).
Break Type: Describes the nature of the discrepancy (e.g., "IDM exists, Target not exists").
Break Count: Indicates how many times this particular break type was found for the user.
Actions: Provides option for viewing the user details for further understanding of the user data

Common Break Types

IDM Exists, Target Not Exists: This indicates that the user or identity exists in the Cymmetri IDM system but does not exist in the target system (e.g., Active Directory).
Target Exists, IDM Not Exists: This indicates that the user or identity exists in the target system but does not exist in the Cymmetri IDM system.

Actions to Resolve Discrepancies

Once discrepancies are identified, administrators can take the following actions:

Manual Review: Examine the discrepancy details and determine if the record should be updated, deleted, or if the discrepancy can be ignored.
Automated Actions: Depending on the configuration, some discrepancies can be automatically resolved by provisioning or de-provisioning the necessary accounts.

Configuring Connector Server

Connectors can be deployed in two ways:

Local connectors are deployed to a Cymmetri instance. This is the usual way how connectors are used. The connector is executed inside a Cymmetri instance, has the same lifecycle (start/stop), etc. Cymmetri can detect local connectors automatically and overall the connector management is easier.
Remote connectors are executed in a different process or on a different node than Cymmetri instance. Remote connectors are deployed to a connector server. There may be need to use a remote connector e.g. to access a file on a remote system (e.g. in case of CSV connector) or because of platform incompatibilities (e.g. .NET connectors)

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

Connector servers are available for both Java and .NET.

Java Connector Server

Installing a Java Connector Server

Minimum Requirements:

Java 1.6 or later for 1.4.X.Y / Java 1.8 for 1.5.X.Y
Refer to your Java connectors to determine if there are any additional requirements

Create your execution environment

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

Test your execution environment

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

Linux / MacOS: ./bin/ConnectorServer.sh
Windows: \bin\ConnectorServer.bat

You should see the following output:

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

Configure your Java connector server

Run the connector server with the setkey option as described below to set your desired key into your properties file
- Linux/ MacOS: ./bin/ConnectorServer.sh -setkey <key> -properties conf/ConnectorServer.properties
- Windows: bin\ConnectorServer.bat /setkey <key> /properties conf\ConnectorServer.properties
For all other properties (e.g. port), edit the conf/connectorserver.properties manually. The available properties are described in the connectorserver.properties file.

Running your Java connector server

Run the server by launching with the -run option:

Linux / MacOS: ./bin/ConnectorServer.sh -run -properties conf/ConnectorServer.properties
Windows: bin\ConnectorServer.bat /run -properties conf\ConnectorServer.properties

Installing Connectors on a Java Connector Server

To deploy a Java connector:

Copy the Java connector bundle jar file into the bundles directory in your Java connector server directory
If necessary, add to the classpath any 3rd party jars required by any Java connector
Restart the Java connector server

Using SSL to communicate with connector servers

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

Deploy an SSL certificate to the connector server's system.
Configure your connector server to provide SSL sockets.
Configure your application to communicate with the communicate with the connector server via SSL.

Configure your application to use SSL

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

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

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

.NET Connector Server

Installing a .NET Connector Server

Minimum Requirements:

Windows Server 2003 or 2008
.NET Framework 3.5 or higher
Refer to your .NET connector to determine if there are any additional requirements

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

Configuring the .NET Connector Server

ConnectorServer /setkey <newkey>

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

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

Additional Notes about configuration

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

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

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

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

Host name or IP address
Connector server port
Connector server key
Whether SSL is enabled

Changing Trace Settings

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

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

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

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

Running the .NET Connector Server

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

ConnectorServer /run

Installing Connectors on a .NET Connector Server

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

Running Multiple Connector Servers on the Same Machine

Assigning Applications to End Users

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

Application Assignment

There are three ways in which applications can be assigned to users:

Admin may assign an application directly to a user.
Admin may map an application to a group; and the user is added to the group or is already part of the group.
End User may request an application and is granted access to the application.
Bulk Assignment of application to a set of users

Let us understand the flow for each of the above mentioned scenarios:

1. Admin assigns an application directly to the end user

Users with admin roles such as Organization Admin, Domain Admin, or Application Admin on the Cymmetri platform can assign managed applications to end-users .

First, we need to add the application to the Cymmetri platform
Next, we move to configure the application to assign it to an end user.
Click on the application tile to configure it.

The flow for assignment goes as follows -

Description:

Admin clicks on the application tile, and starts the configuration.
Click on the Assignments tab on the left hand side menu.
Click on the “Assign New” button on the Users menu.
Search for a user in the search text box, and once the user is found, click on the “Assign” button.
Here we need to decide whether we want to provide a Lifetime Access or a Time Based Access
1. Lifetime Access: Users have access to the application without any time restrictions.
2. Time Based Access: Users have access to the application only for the specified range of time. We need to provide a Start Date & Time and an End Date & Time for Time Based Access.
Now click on Save to register a request for the application assignment. If no Workflow is configured for the said application the application is immediately assigned to the user.
If a workflow for application provisioning is configured then the workflow is been initiated.
The workflow approver will then receive a request to approve the user assignment in their inbox.
Now the approver may approve or reject the user assignment
The approver may change the start and end date, if required; refer to the dynamic form attributes passed during the application assignment.
To continue the flow click on Accept button.
Now the next level of approver will be able to see the previous levels of approval, and similar to the previous level of approval, the approver may change the start and end date, if required; refer to the dynamic form attributes passed during the application assignment.
Click “Accept” to proceed.
After the last level approver has also approved the assignment, the backend processes will run the application provisioning flow.
Once the user has been provisioned in the application, they will be able to see it in their list of applications.

2. Admin assigns an application directly to a group

First, we need to add the application to the Cymmetri platform
Next, we move to configure the application to assign it to a group.
Click on the application tile to configure it.

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

Description:

Click on the application tile, and start the configuration.
Click on the Assignments tab on the left hand side menu.

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

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

5. Checking for the users who belong to the group, we can see that the application has been assigned.

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

3. User requests for an application

Users on the Cymmetri platform can request access to a managed applications as a Self-Service feature.

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

Description:

Visit the “My Workspace” menu.
Click on the “My Access” left-hand side menu.

3. Now Click on the “+ Request” button on the top-right button.

4. Click on the Application Icon to start the request process

Here we need to decide whether we want to provide a Lifetime Access or a Time Based Access
1. Lifetime Access: Users have access to the application without any time restrictions.
2. Time Based Access: Users have access to the application only for the specified range of time. We need to provide a Start Date & Time and an End Date & Time for Time Based Access.
Now click on Save to register a request for the application assignment. If no Workflow is configured for the said application the application is immediately assigned to the user.
If a workflow for application provisioning is configured then the workflow is been initiated.
The workflow approver will then receive a request to approve the user assignment in their inbox.
Now the approver may approve or reject the user assignment
The approver may change the start and end date, if required; refer to the dynamic form attributes passed during the application assignment.
To continue the flow click on Accept button.
Now the next level of approver will be able to see the previous levels of approval, and similar to the previous level of approval, the approver may change the start and end date, if required; refer to the dynamic form attributes passed during the application assignment.
Click “Accept” to proceed.
After the last level approver has also approved the assignment, the backend processes will run the application provisioning flow.
Once the user has been provisioned in the application, they will be able to see it in their list of applications.

4. Bulk Assignment of application to a set of users

Click on Identity Hub > Applications menu and then click on the Applications Assignments button.

A screen pops up that lets you select the csv file you want to upload that contains the list of users to whom the application needs to be assigned, 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.
Once you have ensured the parameters are correct next select the application that needs to be assigned and click on Next button.

Match the Column names from the CSV file with the corresponding attributes using this File Info dialog box and click on the Import button.

Note: The "Link Application" check box is available to provision the user in the target application

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

If any workflow is configured on the application provisioning then the corresponding workflow is triggered after the successful completeion of assignment as shown below: