Once the managed application has been added to your Cymmetri Identity platform tenant, you will be able to assign applications to your end-users.
There are three ways in which users may 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.
There are flows in which is user is assigned to the application
Users of the Cymmetri Identity platform deployment having admin roles among Organization Admin, Domain Admin, and Application Admin, will be able to assign an end-user to a managed application.
First, we need to add the application to the Cymmetri Identity platform deployment for managing it through Cymmetri deployment.
Next, we move to configure the application to assign it to an end user.
Click on the application tile to configure it.
The flow for assignment goes as follows -
Admin clicks on the application tile, and starts the configuration.
Click on the “assign new” button on the users menu.
We see the following fields here -
Start Date - When the user will be assigned the application.
End Date - When the user will be deprovisioned from the application.
Lifetime Access - If selected, the user will be assigned the application for the entire duration that they are active in the Cymmetri Identity platform.
Dynamic Form Fields - Dynamic form fields may be configured by the admin and enabled to allow the administrator to add more user attribute fields.
Preferred Username - Mandatory text field
Request Additional Modules - Optional Radio button
This step shows that the workflow has been initiated for the user. This is because, we have enabled the workflow for application provisioning (user assignment) for this managed application.
The approver may change the start and end date, if required; refer to the dynamic form attributes passed during the application assignment.
Let us click on accept to continue the flow.
Let us click “Accept” to proceed.
After the last level approver has also approved the assignment, the backend processes will run the application provisioning flow.
Once the user has been provisioned in the application, they will be able to see it in their list of applications.
Users of the Cymmetri Identity platform deployment having admin roles among Organization Admin, Domain Admin, and Application Admin, will be able to assign an entire group of users to a managed application.
First, we need to add the application to the Cymmetri Identity platform deployment for managing it through Cymmetri deployment.
Next, we move to configure the application to assign it to a group.
Click on the application tile to configure it.
The flow for assigning a group to an application goes as follows -
Admin clicks on the application tile, and starts 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.
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.
Users of the Cymmetri Identity platform deployment will be able to request for access to a managed application.
The flow for an end-user to request for an application is as follows -
User visits their “My Workspace” menu.
Click on the “My access” left-hand side menu.
5. We see the following fields here -
a. Start Date - When the user will be assigned the application.
b. End Date - When the user will be deprovisioned from the application.
c. Lifetime Access - If selected, the user will be assigned the application for the entire duration that they are active in the Cymmetri Identity platform.
d. Dynamic Form Fields - Dynamic form fields may be configured by the admin and enabled to allow the administrator to add more user attribute fields.
i. Preferred Username - Mandatory text field
ii. Request Additional Modules - Optional Radio button
This step shows that the workflow has been initiated for the user. This is because, we have enabled the
workflow for application provisioning (user assignment) for this managed application. The workflow approver will then receive a request to approve the user assignment in their inbox.
Now the approver may approve or reject the user assignment
The approver may change the start and end date, if required; refer to the dynamic form attributes passed during the application assignment. Let us click on accept to continue the flow. Now the next level of approver will be able to see the previous levels of approval, and similar to the previous level of approval, the approver may change the start and end date, if required; refer to the dynamic form attributes passed during the application assignment.
Let us click “Accept” to proceed. After the last level approver has also approved the assignment, the backend processes will run the application provisioning flow. Once the user has been provisioned in the application, they will be able to see it in their list of applications.
Dynamic Form allows the administrator to request additional fields from the administrator or the end user assigning the applications to collect additional user fields to be used for provisioning the user into the managed application.
Creating a dynamic form involves the administrator configuring the managed application by clicking on the left-hand side menu item “forms”.
You may now load the default form by clicking on the “Load Sample form”
You may now edit the default form, a preview of the form will be shown on the right hand side.
Let us imagine a simple form that can capture “Preferred Username” [text field] and “Request Additional Modules” [Radio] with two options “Admin” and “Readonly”.
Click on the save button.
Now click on the “Confirm” button in the popup to enable the form for the application.
Click on the assignments tab on the left hand side menu.
Search for a user in the search text box, and once the user is found, click on the “assign” button.
Now click on save to register a request for application assignment.
This will raise a request to provide “lifetime” access to the user with the given custom attributes.
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
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.
5. Checking for the users who belong to the group, we can see that the application has been assigned.
3. Now Click on the “+ Request” button on the top-right button.
4. Click on the Application Icon to start the request process
Now click on save to register a request for application assignment.
This will raise a request to provide “lifetime” access to the user with the given custom attributes.
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.
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
Unzip it in a directory of your choice (e.g. /usr/jconnserv
) on the host where you wish to run the Java connector server
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:
Run the connector server with the -setKey
option as described above to set your desired key into your properties file
For all other properties (e.g. port), edit the conf/connectorserver.properties
manually. The available properties are described in the connectorserver.properties
file.
Run the server by launching with the -run option:
Linux / MacOS: ./bin/ConnectorServer.sh -run -properties conf/connectorserver.properties
Windows: \bin\ConnectorServer.bat -run conf\connectorserver.properties
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
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.
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.
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.
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:
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.
The port, address, and SSL settings are in the tag called AppSettings
, and look like this:
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
Trace settings are in the configuration file. The settings look like this:
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.
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:
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.
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.
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.
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 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.
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 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 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.
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.
Applications menu in the administration page displays the various options pertaining to the Application Management processes.
Applications menu may be accessed by two ways -
Identity Hub
Login as one of the following administrators - Organization Administrator, Domain Administrator, Application Administrator.
Click on the Identity Hub icon on the left side bar.
Click on the Applications text on the slide out bar.
Single Sign On Module
Login as one of the following administrators - Organization Administrator, Domain Administrator, Application Administrator.
Click on the Products menu icon on the left side bar.
Click on the Single SignOn Module icon in the popup list.
4. Click on the Applications text on the slide out bar.
Applications supported by the Cymmetri Identity platform fall majorly into three categories -
Pre-configured Applications These are the applications that have already been configured by the Cymmetri Identity platform for provisioning on cloud or on-premises.
Custom Applications for Provisioning These are the applications that you wish to manage through Cymmetri and support the generic connectors that the Cymmetri Identity platform provides.
Custom Applications for Single SignOn only When you need to add an application for the purpose of performing only Single SignOn for them, Cymmetri provides the ability to add a custom application which may be configured for Single SignOn using the supported Single SignOn mechanisms.
Once you have chosen the application to be added from the above categories, you are ready to add a new application.
1. Click on the “Add New” button on the top-right corner in the Applications menu.
3. Now click on the tile shown in the list below to open the right slide out menu for renaming application as shown below.
4. Add your custom label (if you wish) in the text box and click on the “Add Application” button.
Application has been successfully added to your listing now. You may click on the configure now button to start configuring the application.
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.