Connectivity is critical to successful IAM deployments. SailPoint is committed to providing design, configuration, troubleshooting and best practice information to deploy and maintain connectivity to target systems. SailPoint IdentityIQ enables you to manage and govern access for digital identities across various applications in your environment. Connectors are the bridges that IdentityIQ uses to communicate with and aggregate data from applications. SailPoint IdentityIQ provides a wide range of OOTB connectors that facilitate integration with variety of systems, applications and data sources. These connectors are designed to simplify the process of managing Identity information and access across different platforms.
The custom logic which you want to implement using this custom connector shall be developed in the specified methods.
Once code development is completed, Custom connector code with all the classes must be compiled and packaged to a JAR file.
And the JAR file must be placed in WEB-INF/lib folder of IIQ Installation directory
Defining Connector type in Connector Registry
Connector Registry is an XML file present in IdentityIQ as Configuration object. This file contains the information about all the different connectors and their related details.
Now that we have created a new connector in our IdentityIQ, we have to declare its information and details in Connector Registry.
Here we will create an xml file consisting of the details pertaining to our custom connector. Once we Import this xml file into IdentityIQ, it will be merged with the existing Connector Registry file in IdentityIQ database allowing IdentityIQ to create a new entry in the list of connectors.
Alternatively, the Connector Registry could be manually edited through the Debug page.
Defining .xhtml page which specifies required and optional connection parameters.
Usually, some parameters are required to define the connection to the target resource (e.g. host, port, username, password, etc.).
To allow these parameters to be specified through the UI for each application that uses this connector, an .xhtml page must be written to define how the Application Configuration user interface will request and record those parameters.
This file must be placed in the [IdentityIQ Installation Directory]/define/applications/ directory and must be referenced in the application definition’s XML as the “formPath” entry.
Testing the connector by Creating an application which uses this connector.
Finally, after completing all the development related activities, one must start the application server which is hosting IdentityIQ.
An Application object must be created for using the IdentityIQ’s UI. Select the configured custom connector as application type to tie it to the connector registry configuration and specifying any connection parameters through the configuration.
Once the application is onboarded, we can perform all the configured functionalities in it and verify back the results within the targeted external application.
Alternatively, Applicationconnector can be tested from the integration console (run iiq integration from the [IdentityIQ Installation Directory]/WEB-INF/bin directory).
This type of trigger is used to give the custom application an ability to answer back to a trigger event sent by the trigger service. This integration is bi-directional. A response from the custom application is required for a trigger invocation to be considered complete and successful.
This type of trigger is used to notify the custom application of a particular occurrence of an event. This integration is uni-directional. Trigger invocation is successful the moment the trigger service notifies the external application, and it does not require a response from the custom application.
For example, a user from IT department is able to see Jira, Bitbucket, Administrative / Privileged access across applications like Active Directory, ServiceNow and various other applications in the request center. For a user from Marketing department, the above access is not relevant and with segments, we are abstracting those items. The relevant access for marketing users would be Salesforce CRM and the same will be visible for the users.
In the presentation below, we will be discussing about segments feature in detail :
In the below video, we will provide a practical demonstration on how to configure segments, how it affects the end user perspective using a practical use-case :
Limit end user visibility for applicable access
Only the access that is applicable for a subset of identities and relevant for them is displayed using segments. This helps in avoiding the confusion in finding the right role/access profile while making an access request.
Reduce incorrect access requests
End users shall not make any incorrect access requests because the only access items that they’ll see in the request center are already fine tuned and configured according to the organizational requirement.
Limit accidental provisioning
If presented with a lot of access items, users might request for something that they don’t need. This can be avoided by creating and assigning users to their respective segments based on certain criteria.
Reduce cost of software licensing
Due to accidental access provisioning, users might be consuming additional licenses for access that they do not need which is a major costing risk. This can be avoided by configuring segments.
In this blog we are discussing about the benefit of implementing ERP by comparing it with the traditional method and also about securing it with the help of IAM modules. The blog also mentioned about the SAP (System applications and Product) which is a top ERP solution, it has positioned as a leader in Gartner’s Magic quadrant for single instance ERP, for multiple consecutive areas as per different evaluation criteria.