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

  • 1.3.3.1

  • 1.4.5.1

  • 1.5.0.1

  • 1.5.1.0

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

In this section, we will provide you with detailed information about the types of applications and connectors supported by Cymmetri

Supported Pre-configured Applications

Cloud Based Applications

Cymmetri seamlessly integrates with various cloud-based applications to help you efficiently manage user access and entitlements. The following are the pre-configured cloud-based applications that Cymmetri supports:

1. Azure: Manage user access and entitlements within your Microsoft Azure environment effortlessly.

2. Google Workplace: Simplify access management for Google Workspace applications, including Gmail, Google Drive, and more.

3. ServiceNow: Effectively control access to your ServiceNow instance to enhance security and compliance.

4. Salesforce: Streamline Salesforce user access management for better control and auditing.

5. SCIM v2.0 (Salesforce): Utilize the System for Cross-domain Identity Management (SCIM) 2.0 protocol specifically for Salesforce integration.

6. Github (Using SCIM 2.0 connector): Manage user access to GitHub repositories efficiently through our SCIM 2.0 connector.

On-Premises Applications

Cymmetri extends its support beyond cloud-based applications to include various on-premises applications. Here are the on-premises applications supported by Cymmetri:

1. Active Directory: Efficiently manage user access to your Windows Active Directory resources.

2. OpenLDAP: Simplify access control for your LDAP directory services with Cymmetri's integration.

3. Lotus Notes: Streamline user access management for Lotus Notes applications.

4. Powershell: Integrate and manage access to PowerShell scripts and resources seamlessly.

5. CSV Directory: Effectively manage user access within CSV-based directory services.

Supported Connectors

Cymmetri offers versatile connector support to ensure seamless integration with a wide range of applications. Here are the supported connectors categorized by deployment type:

Using Cloud Connector

Cymmetri's Cloud Connectors are designed to simplify access management for various cloud-based applications. Supported cloud connectors include:

1. Azure: Easily manage access to Microsoft Azure resources with our cloud connector.

2. Google Workplace: Streamline access management for Google Workspace applications using our cloud connector.

3. ServiceNow: Control access to your ServiceNow instance efficiently with our cloud connector.

4. Salesforce: Seamlessly manage user access to Salesforce through our cloud connector.

5. SCIM 1.1: Leverage the SCIM 1.1 protocol for connector support, ensuring compatibility with various cloud services.

6. SCIM 2.0 (Basic, Bearer, Fixed Bearer): Our platform supports multiple SCIM 2.0 authentication methods to accommodate diverse integration needs.

Using Locally Deployed Connector

For on-premises applications and custom integration scenarios, Cymmetri offers locally deployed connectors, providing flexibility and control. Supported locally deployed connectors include:

1. Active Directory: Manage access to Windows Active Directory resources seamlessly using our connector.

2. Custom Script for Databases: Custom Script based connectors using groovy scripts for database applications, tailored to your specific requirements.

3. LDAP: Integrate and manage access to LDAP-based directory services through our connector.

4. Lotus Notes: Simplify user access management for Lotus Notes applications with our connector.

5. Powershell: Seamlessly integrate and manage access to PowerShell resources using our connector.

6. REST API: Extend your integration capabilities with Cymmetri's support for RESTful API connectors leveraging the flexibility of Groovy and UI based scripts.

Cymmetri's comprehensive support for both pre-configured applications and versatile connectors ensures that you have the tools needed to efficiently manage user access and entitlements across a diverse range of applications and environments. For detailed setup instructions and configuration guidelines, please refer to the specific documentation for each application and connector.

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.

Github Enterprise provides provisioning using SCIM 2.0

Pre-requisites

1. Create an account in Github (Enterprise).

2. Enable SAML for the Github tenant to be used with Cymmetri.

Step 1. Configure SSO in Cymmetri

Note the application URL received from the Git SAML configuration

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

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

https://www.samltool.com/format_x509cert.php

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

Configure Profile Mapping

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

Test SSO with the Cymmetri user.

1. Configure SCIM v2.0 (Github) application from master (cymmetri).

2. Basic provisioning policy attribute and policy map already aaded in default schema.

3. Github Application is run using Fixed Bearer token.

4. To get Fixed bearer token following steps used.

Step 1: Go to user settings in github

Step 2: Go to developer settings

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

Step4: Click on Configure SSO

Step 5: Click on Authorize

1. Use following cymmetri provision configuration and change according to github account.

2. Fixed Bearer Value copy from personal access token

3. Click on save

4. Click on Test Configuration with success message.

5. Check Policy map

6. Disable default for the respective attribute

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

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

1. Refer following document to configure azure application

2. Azure Document https://connid.atlassian.net/wiki/spaces/BASE/pages/308674561/Azure [ConnID]
3. Create a new OAuth2 Application and provide the following configuration in Azure OAuth2 application.

4. Application will be created and now we will be able to configure.
5. Let us now click on Authentication tab on the left-hand side menu. We can choose account either in a single Organization Directory or multiple directory.
6. Click on Add a platform and we can add a new Redirect URI as “http://localhost”.
7. Further we can allow the Public Client flows.
8. Create a new Secret by first, clicking on Certificate and Secrets on the left-hand side menu, and then click on the “+ New Client secret” link, Enter Description and select the Expires option.
9. Provide the right permissions for the Connector to work by clicking on API Permissions tab on the left-hand side menu, then click on Add, then click on Microsoft Graph and then click on Application Permission and Delegated.
10. Search and select the following permissions/scopes in OpenID

    1. APIConnectors.Read.All

    2. Directory.ReadWrite.All

    3. OpenID

    4. PrivilegedAccess.Read.AzureAD

    5. User.ReadWrite.All

11. We need to take consent from admin for getting access to Microsoft Graph API, Click on add permission, Click on “Grant Admin content for Unotech Software”, and finally Click on Yes.
12. Click on Expose an API and Click on Set to expose the API to be used by the Azure API client on the connector.

Configuration on Cymmetri Identity Platform for Azure provisioning

1. Configure Azure user and server config as follows:
2. Configure the User Configurations

   1. Copy the application authority from the User Configure.

   2. Configure the Client ID.

   3. Configure the Client Secret.

   4. Configure the Domain from Azure Active Directory.
   5. Configure the Redirect URI exposed from the Azure AD.

   6. Graph API base endpoint (User Config Resource URI)

   7. Add the Azure Tenant ID

   8. Choose the base username.

Click on Save, and test the connection.

Configuration on Cymmetri Identity Platform for Active Directory

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

Ensure that all your object classes are included here in the Entry object classes.

Configure the root suffix, which is the base DC and configure the Principal password.

Base Contexts for group entry searches is the base DN for searching for groups in the AD. Change the server hostname and use the domain name instead of IP address.

Enter the principal as the manager’s principal name, the principal is the user account that will be used for making LDAP queries to the Active Directory. SSL must always be true.

Test AD configuration before assigning an application to any user.

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

1. The Cymmetri Identity platform Active Directory provisioning supports the following functions -

   1. Create user

   2. Update user

   3. Delete user

Server hostname needs to be configured for public access

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:

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

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

1. Edit the default form, a preview of the form is shown on the right hand side.

2. Let us create a simple form that can capture

   1. “Preferred Username” [text field] and

   2. “Request Additional Modules” [Radio] with two options “Administrator” and “Read Only”.

1. Click on the Save button.

1. Click on the “Confirm” button in the popup to enable the form for the application.

Integration with Powershell

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

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

Integration with LDAP

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

   Host/IP

   LDAP Base Context

   service user (Manager Username)

   password (Manager User password)

2. After configure LDAP server we need to configure the Ldap application into the Cymmetri.
3. Check policy map to add proper attributes as needed by LDAP schema.

Accessing the Applications Menu

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

Applications menu can be accessed in two ways:

Identity Hub

1. Login as either an Organization Administrator, Domain Administrator, or Application Administrator.

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

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

Single Sign On Module

1. Login as either an Organization Administrator, Domain Administrator, or Application Administrator.

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

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

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

Understanding the applications supported by Cymmetri

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

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

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

3. 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 your desired connector (e.g., REST) or choose the “Custom” application type from the available application catalogue.

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.

Google Apps is a software-as-a-service platform (SAAS) that provides email, calendar, documents and other services. This connector uses the Google Apps provisioning APIs to create, add, delete and modify user accounts and email aliases.

Note: 1. Only the Premium (paid) or Educational versions of Google Apps provide access to the provisioning APIs. 2. Connector will not work on the free Google Apps Domain

Configuration

1. First obtain the client_secret.json file from your Google Apps instance -

   1. Log in to your Google Apps Admin Console (at ) and verify that Security > Enable API access is checked (For more information on these APIs, navigate to the Google Developers interface, and search for these APIs).

   2. In the OAuth 2.0 application of choice (at ), create credential of type Oauth Client ID / Other, then download the related client_secrets.json file.

Enter

1. Create New Project
2. Click on Enabled API & Services
3. Search for Admin SDK API
4. Click on Admin SDK API and then click on the Enable button
5. Once enabled, Click on CREDENTIALS tab
6. Now click on Create Credentials
7. And select OAuth client ID option
8. Select Desktop app as Application type, provide a name for the OAuth 2.0 client and then click on the CREATE button
9. A response screen is visible that shows that the "OAuth client created" It also displays Your Client ID and Your Client Secret. You may download the JSON here using the DOWNLOAD JSON option.
10. Click on OAuth consent screen and then Click on edit app

11. Enter the required details and Click on save and update

1. Select Internal as User Type if you want to restrict access only to the users of your organization.

   Click on SAVE AND CONTINUE button on the Scopes screen
2. Search for Admin SDK API and select
3. Select for group
4. Click on credential

5. Download OAuth client

6. Change to the directory where you have downloaded the bundle and run the following command on the client_secrets.json file that you obtained earlier in this procedure:

This command opens the default browser, and loads a screen on which you authorize consent to access the Google Apps account.

When you have authorized consent, the browser returns a code. Copy and paste the code into the terminal from which you ran the original command

A response similar to the following is returned.

Once the above information is obtained we need to configure the Google App in Cymmetri with Server Configuration and User Configuration as shown below:

Integration SCIM v2.0 with Basic

1. Any application which supports SCIM v2.0 with basic authentication is workable for application.

2. Following are configuration which is used for SCIM with basic authenticator.

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

2. Username - Username to authenticate SCIM API endpoint.

3. Password - Password to authenticate SCIM API endpoint.

4. Authentication type - It is Fixed Bearer compulsory.

5. Update method - Patch or Put method.

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

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

Integration REST Application

1. The REST connector is designed to manage provisioning by relying on RESTful service.

2. For REST applications we need target applications which support REST API’s.

3. Following configuration is tested for felicity application.

4. We need REST API’s to integrate with cymmetri.

5. Following are the cymmetri configuration which need to configure in user configuration in cymmetri.

6. It is Basic REST configuration which need to configure in application.

1. We need to provide Groovy code to run create user, update user, delete user and also recon pull and push (for recon pull we need to add sync script and for recon push we need to add search script)

2. For sample script please validate following link

Note: Please Configure script step by step

1. Configure test script at initial step and then test configuration for provided script (If configure successfully then only go for step b).

2. Configure create script and test configuration (If successfully configured then only go for step c).

3. Configure update script and test configuration (If successfully configured then only go for step d).

4. Configure delete script and test configuration (If successfully configured then only go for step e).

5. Configure sync(pull) script and test configuration (If successfully configured then only go for step f).

6. Configure search(push) script and test configuration (If successfully configured then only go to the next step).

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:

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

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

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

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:

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

2. Click on the Assignments tab on the left hand side menu.
3. Click on the “Assign New” button on the Users menu.
5. 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.

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

7. If a workflow for application provisioning is configured then the workflow is been initiated.

8. The workflow approver will then receive a request to approve the user assignment in their inbox.
9. Now the approver may approve or reject the user assignment
10. The approver may change the start and end date, if required; refer to the dynamic form attributes passed during the application assignment.

11. To continue the flow click on Accept button.

12. 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.
13. Click “Accept” to proceed.

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

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

1. First, we need to add the application to the Cymmetri platform

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

3. Click on the application tile to configure it.

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

Description:

1. Click on the application tile, and start the configuration.

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

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

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

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.

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:

1. Visit the “My Workspace” menu.

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

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

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

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

3. If a workflow for application provisioning is configured then the workflow is been initiated.

4. The workflow approver will then receive a request to approve the user assignment in their inbox.
5. Now the approver may approve or reject the user assignment
6. The approver may change the start and end date, if required; refer to the dynamic form attributes passed during the application assignment.

7. To continue the flow click on Accept button.

8. 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.
9. Click “Accept” to proceed.

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

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

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

The reconciliation process may follow two strategies -

1. Full Reconciliation Full reconciliation is typically carried out when the managed application is first introduced into an organization’s Cymmetri platform. This involves ensuring all user accounts (and group accounts, wherever applicable) from the Cymmetri platform, are synchronized with the account information on the managed application. This type of reconciliation often takes a longer time, and is often only used as a one-time activity.

2. Filtered Reconciliation The Cymmetri platform and the managed application might lose synchronization due to a number of reasons, including backend changes to the user or group account information on the managed application or failure of communication between the identity platform and the managed application. In such cases, filtered reconciliation is employed on a regular, scheduled basis. This includes filters for a particular set of users, or to choose only the users that have been modified on either platforms, this is known as filtered reconciliation.

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

The reconciliation process involves two major processes:

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

2. Push In this mechanism, the Cymmetri platform pushes the user and group account information to be pushed to the managed application.

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

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

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

1. Name: Refers to the name of the Reconciliation process

2. Modes: FILTERED_RECONCILIATION (Currently the only mode supported by Cymmetri)

3. Sync Fields: The field from the user/group’s account information as available on the Cymmetri platform that must be used as a basis to identify the corresponding account on the managed application database.

4. Source Attributes: The field from the user/group’s account information as available on the managed application database that must be used as a basis to match with the “Sync fields”.

5. Status: Whether to run the reconciliation for Active/Inactive users.

6. Type: Some applications allow GROUP reconciliation, but most will have USER reconciliation only.

Filled Reconciliation basic configuration looks as above.

Synchronizing Scenarios and Their Corresponding Outcomes

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

Following are the scenarios managed by the Cymmetri platform -

1. User does not exist in Target system & exists in Cymmetri: This indicates a situation during a pull phase or a push phase, where the user account exists on the Cymmetri platform, but not in the managed application. This typically occurs when the users have been pulled into the Cymmetri platform, but the managed application is yet to be synchronized with these users.

2. User exists in Cymmetri & Target system: This indicates a situation during a pull phase or a push phase, where the user account exists on the Cymmetri platform and in the managed application, but they may or may not have the same attributes or the same values of the attributes.

3. User exists in Target system & does not exist in Cymmetri: This indicates a situation during a pull phase or a push phase, where the user account exists in the managed application database but not on the Cymmetri Identity platform. This typically occurs when the users have been pulled into the managed application through its backend and the users have not been centrally managed through the Cymmetri platform.

Conditions Explained:

1. User does not exist in Target system & exists in Cymmetri:

   1. PROVISION: User is created in the target system with the attributes as present in their Cymmetri user profile.

   2. IGNORE: User is not modified in either system.

   3. UPDATE: Not relevant for this scenario.

   4. DEPROVISION: User is removed from the Cymmetri platform to be consistent with the managed application user database.

   5. UNASSIGN: Not relevant for this scenario.

   6. ASSIGN: User is assigned access to this system in Cymmetri, this option may be used in the case of options like JIT being available to generate user profile in the managed application.

   7. UNLINK: Not relevant for this scenario.

   8. LINK: Not relevant for this scenario.

2. User exists in Cymmetri & Target system:

   1. PROVISION: User is created in the target system with the attributes as present in their Cymmetri user profile.

   2. IGNORE: User is not modified in either system.

   3. UPDATE: User information from the Cymmetri Identity platform is updated using the account information from the managed application and vice versa.

   4. DEPROVISION: Not relevant for this scenario.

   5. UNASSIGN: Not relevant for this scenario.

   6. ASSIGN: User is assigned the managed application on the Cymmetri platform in case they are already not assigned.

   7. UNLINK: Not relevant for this scenario.

   8. LINK: Not relevant for this scenario.

3. User exists in Target system & does not exist in Cymmetri:

   1. PROVISION: User is created in the Cymmetri Identity platform deployment using the account information from the managed application.

   2. IGNORE: User is not modified in either system.

   3. UPDATE: Not relevant for this scenario.

   4. DEPROVISION: User is removed from the managed application user database.

   5. UNASSIGN: Not relevant for this scenario.

   6. ASSIGN: Not relevant for this scenario.

   7. UNLINK: Not relevant for this scenario.

   8. LINK: Not relevant for this scenario.

Scheduling the reconciliation process:

1. Next Execution Date: This indicates the base date to start the execution date and time of the reconciliation process.

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

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

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

   2. Username - Username to authenticate SCIM API endpoint.

   3. Password - Password to authenticate SCIM API endpoint.

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

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

   6. Client Id - client id for authentication

   7. Client Secret - client secret for authentication

   8. Authentication type - It is Fixed Bearer compulsory.

   9. Update method - Patch or Put method.

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

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

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

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

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

1. Any application which supports SCIM v2.0 with fixed bearer is workable for application.

2. Following are configuration which is used for SCIM with fixed bearer

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

2. Username - Username to authenticate SCIM API endpoint.

3. Password - Password to authenticate SCIM API endpoint.

4. Authentication type - It is Fixed Bearer compulsory.

5. Fixed Bearer Value - The value for fixed bearer.

6. Update method - Patch or Put method.

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

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