Let us have an overview on the difference between the cloud rules & connector rules
Cloud Executed rules are running in the cloud within the Identity Now tenant. Connector rules run on the virtual appliance which is on-premise inside the customer’s data center
Cloud Execution Rule :
Cloud executed rules, as the name implies, are executed within the Identity Now multi-tenant environment.
They typically have independent functions for a specific purpose. For example, calculating an Identity attribute value.
Cloud executed rules typically need to query the Identity Now data model in order to complete their work.
The rule might need to guarantee uniqueness of a value and it would generate a value and query Identity Now to determine if that value already exists.
Access to any Identity Now data is read-only and you can’t make any calls outside of Identity Now such as a REST API from another vendor service.
Because they run in a multi-tenant environment, the are put in a very restricted context and there is a great deal of scrutiny taken during the required review process for rules.
We will cover the review process that is required when a cloud-executed rules is submitted later in the presentation.
Of course, this all makes sense as you cannot allow rules to effect other tenants if they are poorly written.
You also have to restrict the rules context so they can’t access any data from another tenant and things along those lines.
Connecter Execution Rule :
Connector executed rules do not run in the cloud which is fairly obvious based on the name.
These rules instead run on the VA itself. So they are running in the customers data center and therefore they are not running side by side with services from another tenant.
They are usually extending the connector capabilities. The functions that they perform are quite complex.
They do NOT have access to the Identity Now Data Model because they are executing on a virtual appliance.
The huge difference here is that they are not subject to a review process by SailPoint. These rules can be uploaded via the REST API and are significantly easier to work with. With that said you still want these rules to be well written.
The simple fact is that the possible negative effect of a poorly written connector rule is limited because it is not running within the Identity Now tenant.
SailPoint Provides us with six APIs to perform connector rule operations mentioned below :
GET, LIST, CREATE, UPDATE, DELETE, VALIDATE are the APIs that are currently used for connector rule operations.
A token with ORG_ADMIN authority is required to perform any operation.
Rule Examples
Example usage:
Calculate complex identity attributes.
Calculate complex account attributes.
Provide connector logic
Connector rule Example – If there is a requirement to disable the account based on the number of entitlements or the account should be disabled automatically based on role revocation, this can be achieved by writing a connector rule
Cloud rule Example– This can be used for generating a unique email id which can scan the existing email id’s and generate a unique id for every joiner.
Please subscribe to our social media and stay updated with latest technology content. Thanks you.
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.
In SailPoint IdentityIQ, a Custom Connector is a specialized integration component that allows the IdentityIQ platform to connect and interact with external systems, applications, or data sources that are not supported by the standard OOTB connectors. Custom connectors extend the capabilities of IdentityIQ by enabling it to manage identity-related information in a wider range of systems.
High level architecture of Custom connector
Custom Connector Development
Developing Custom connector in SailPoint IdentityIQ involves creating a Java-based implementation that adheres to the connector framework and API provided by SailPoint.
This allows you to define the interaction between IdentityIQ and the specific external system you want to integrate with. A typical development of custom connector includes 4 steps –
Creating a new implementation of functionality and packaging it into JAR file.
The custom connector uses the openconnector framework provided by SailPoint in the openconnector package where there are lot of methods provided for different type of operations.
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 console can be used to test the various features of your connector including Aggregation and Provisioning.
The following presentation gives you clear understanding of custom connector development in detail.
Before going through the Integration of Genie with SailPoint IdentityIQ, let us understand what a ticket and a ticketing system is.
What is a ticket?
A Ticket is a special record that represents an incident, request or event that requires action from the IT department. It contains the necessary details of the incident, request or event.
A ticketing system is a software platform designed to manage and track customer support requests. It streamlines the process of resolving customer issues, making it easier for businesses to provide fast and effective support.
Benefits of embracing a ticketing system in your organization:
Control High Volume of Requests from a Centralized Place – Organizations can track and manage inbound support requests with the help of a good ticketing system. The solution can be used by executives to manage support cases more efficiently while still attending to all client issues.
Combine interactions into one thread – Your team can use ticketing system to combine customer-related conversations into a single thread when offering customer care to clients via a variety of channels.
Process automation and workload management – Ticketing systems provide several potentials for automation. As an illustration, the software gathers assistance requests from several sources before automating the creation of tickets. Regardless of the help channel clients select, tickets are automatically created whenever they submit requests.
Adequate team collaboration – Ticketing systems provide a platform to the customer service representatives to collaborate among themselves in assigning tickets to senior associates in terms of P0 escalations.
About Genie:
Genie is a ticketing tool, in which there are different types of tickets such as Work Order tickets, Incident tickets, etc. SailPoint handles creation of below tickets in Genie from SailPoint.
Onboarding ticket
Exit or Off-boarding ticket
Provision failure ticket
Among the above tickets, Onboarding and Off-boarding tickets are Work Order tickets and Provision failure ticket is an Incident ticket.
Integration with SailPoint IdentityIQ:
Genie is integrated with SailPoint using REST APIs.
Below is the high-level architecture of Genie – SailPoint Integration
High level architecture
Now, let us have a look at the APIs used in the Integration process. Below is the list of APIs used for creating tickets and getting specific ticket details:
Generate Authentication key: We are using this API to generate an Authentication key. Here, the generated Authentication key expires for every few minutes.
Creating Work Order ticket: We are using this API to create a Work Order ticket in Genie.
Get specific Work Order ticket: We are using this API to Get a specific Work Order ticket details. In other words, it is used to Retrieve the Work Order ID of the submitted request.
Creating Incident ticket: We are using this API to create a Work Order ticket in Genie.
Get specific Incident ticket: We are using this API to Get a specific Incident ticket details. In other words, it is used to Retrieve the Incident number of the submitted request.
Prerequisites for integrating Genie with SailPoint:
Following are the prerequisites that are essential for integration of Genie with SailPoint IdentityIQ
Genie API details for creating tickets
Base URL and Authentication details of the APIs
Access to Genie Test Instance
Database table to store the ticket details
Connection details of the Database
Now, let us discuss the use cases involved in the integration process.
Use Cases
Onboarding Ticket Creation:
An Onboarding Work order ticket will be created in Genie from SailPoint when a new joiner joins the organization and his/her account is created in Truth Source and Active Directory applications.
The ticket contains details of the New Joiner such as Start Date, First Name, Last Name, Employee ID, Employment Type, AD ID, Domain ID, Contact Information, etc.
Onboarding ticket creation process
Success case:
Once the ticket gets created in Genie successfully, the details of the created ticket such as Work Order ID, Creation Date, Request ID and ticket summary will be added to the database table.
Failure case:
If the ticket creation fails for some reason, then an Email notification containing the New Joiner’s details, will be triggered to the respective stakeholders.
Exit or Off-boarding Ticket Creation
An Exit or Off-boarding Work order ticket will be created in Genie when HR assigns the Last working date of the user in Truth source and that Last working date is 7 days away from today’s date.
The ticket contains details of the End dated user such as Last Working Date, First Name, Last Name, Employee ID, Employment Type, AD ID, Domain ID, Contact Information, etc.
Exit ticket creation process
Success case: Once the ticket gets created in Genie successfully, the details of the created ticket such as Work Order ID, Creation Date, Request ID and ticket summary will be added to the database table. Failure case: If the ticket creation fails for some reason, then an Email notification with the End Dated user’s details, will be triggered to the respective stakeholders specifying.
Provisioning Failure (Incident Ticket)
A Provisioning Failure (Incident) ticket per application will be created if the provisioning operations failed in SailPoint in last 24 hours. In this use case, applications under consideration are Active Directory, G-Suite and OpenLDAP and operations under consideration are Create, Enable, Disable and Delete.
For example, if the Disable operation failed in Active Directory for an account, then a ticket (which will be of Incident type) will be created in Genie containing the details such as Type of operation failed and Display Name, Employee ID, email, sAMAccountName, userPrincipalName, distinguishedName, etc details of the account.
Provisioning Failure ticket creation process
Success case:
Once the ticket gets created in Genie successfully, the details of the created ticket such as Incident Number, Creation Date, Request ID and ticket summary will be added to the database table.
Failure case:
If the ticket creation fails for some reason, then an Email notification will be triggered to the respective stakeholders specifying Type of operation failed, Application name in which Provisioning failed and Display Name, Employee ID, email, etc. details of the account.
Now, let us understand the advantages of integrating a ticketing system with SailPoint IdentityIQ when compared with a traditional ITSM.
Advantages of Integrating Genie with SailPoint IdentityIQ:
In this integration, we have automated the creation of onboarding tickets for New Joiners. Whereas in traditional ITSM’s, the ticket should be created manually by the end user.
While creating tickets in Genie, SailPoint uses the data coming from Truth Source which will be updated by the HR team. Whereas in traditional ITSM’s, there is every chance that end user does not give the mandatory details required by IT team to perform necessary action on that ticket or the end user mistakenly may also enter incorrect details. So, IT team might need to contact the HR team or the end user, which is a time-consuming process.
In this integration, we will be using the details of the user as per the Truth Source application while creating the ticket. So, the IT team may not wait for the communication from the concerned team.
Whereas in traditional ITSM’s, when the ticket is created, the IT team should get certain required details from the concerned team manually. The Exit ticket will be created automatically when the end-dated user is one week away from the Last Working date, which gives the IT team ample amount of time to take necessary actions such as collection of assets and disabling of access.
In this integration, we are storing the ticket details such as Work Order ID, Incident Number, Creation Date, Request ID and Summary in the database table for all the tickets created from SailPoint. So, we can use this table’s data for auditing purposes which ensures centralized governance.
The Incident tickets are created every day (one ticket per application) from SailPoint in Genie for applications such as Active Directory, G-Suite and OpenLDAP and for operations such as Create, Enable, Disable and Delete, if the provisioning fails in these applications. The point to be noted here is, if in an application, no provisioning operations failed for that day, then no ticket will be created for that application for the particular day. But, there is every chance that, one ticket per application will be created where each ticket contains the information of all the accounts for which Provisioning failed. Using SailPoint, this is one of the critical advantages of integrating genie with SailPoint IIQ. Whereas in traditional ITSM’s, this needs to be done manually, which will be a tedious task to do.
The detailed discussion of APIs, use cases and integration approach is discussed in the following video:
Now, let us a have a demo on integration of Genie with SailPoint IdentityIQ in the following video:
The DocuSign electronic signature app provides users a simplified way to digitally sign and return documents from anywhere in the world.
describes the Integration for the DocuSign Application of SailPoint IdentityIQ (IIQ) solution implementation.
SailPoint webservice connector is application type used to connect from SailPoint to DocuSign application. for creating account, update account, Activate and deactivate account.
Details Required for DocuSign integrate with SailPoint
Need to get the DocuSign API details for the different operation.
Base URL will be different for different environment.
secret key and client ID for the token generation.
The following operation will be performed by IIQ –
Create, Update, Enable, Disable, Account Aggregation, Group Aggregation
Created Account operation: This use case will be used to create the account for the different user with adding the groups, permission, and different details required for the account creation.
Update Account operation : If the existing user need to update the details , where the details can be updated in the form which is provided in the SailPoint.
Leaver Process : As the user will be left the company or the department, then the user will be disabled or deleted automatically by the leaver process.
Mover Process : Once the user is transferred from the one department to other department or to the position is changed of the user then the mover process will be triggered.
Rehire Process: Once the user is re-hired in the organization then the re-hire process will be triggered.
A plugin is a tiny piece of software that extends the functionality of an Application or Computer program.
The IdentityIq Plugin Framework is an protract framework model for IdentityIQ.It allows third parties to develop affluent application and service-level amplification to the core SailPoint IdentityIQ. It enables plugins to extend the excellence in user interface, deliver custom REST endpoints, and to deliver conventional background services.
In the following presentation, I will be providing a brief introduction of IdentityIQ Plugins:
Plugin Versioning Requirements
Plugin version numbers must be numeric, denote the parts of the version number with decimal points, and not contain any alphabetic or other characters in order to better facilitate upgrading plugins. Leading zeroes will be removed from each segment of the version number, and the values between the decimal points are converted to integers.
For example: 06 and 00006 are both interpreted as 6 A segment containing any non-numeric values is interpreted as 0 7.009.alpha is parsed as 7.9.0 5.7.8a is parsed as 5.7.0
Plugin Object Model
The Plugin XML object, which specifies the plugin’s constant, describes a plugin in IdentityIQ. REST resources, Snippets, and settings are a few examples of features. The manifest.xml file contains the definition of the Plugin object. This file is necessary for plugin.
The XML object known as the Plugin Object defines the plugin’s feature. By binding them as attributes of a Plugin Object, this object informs IdentityIQ about the facets that are present in your plugin. You can also specify information about the plugin in the Plugin Object, such its name, the privileges needed to use it, its version, snippets, and REST resources. Use the advanced plugin settings to define a form or to refer to a specific plugin configuration file for more complicated plugins that need support for several field types and more dynamic behavior, such as drop-down lists or password fields. Depending on past selections, dynamic behavior can involve showing or hiding other fields.
For Example: In contrast to when the user picks basic authentication, it could be more acceptable to display an access token field when the user selects o-auth authentication.
Plugin Settings
Attributes that can be changed during installation are known as plugin settings. To view the configuration options page, click Configure. Forms are used to display the settings. The form is generated automatically if the plugin does not use its advanced options. On the plugin settings page, the settings from the manifest file are shown in alphabetical order. A single setting on a plugin’s configuration settings page can be represented by the Plugin setting object. On the settings page, each object serves to represent a single customizable setting.
IdentityIQ stores the .zip archive file of the Plugin in the IdentityIQ database in the spt_file_bucket table. The data in the spt_file_bucket table is a referenced ID to an entry in the spt_persisted_file table.
After establishment or amid an application server restart, plugins are stacked from this.zip file. All consequence files are taken from the.zip file and cached for ensuing utilization. The cached files can be gotten to using a assortment of accessor ways, but they can moreover be retrieved by utilizing
the URL prefix /identityiq/plugin/pluginName taken after by the way indicated within the construct structure. The PluginClassLoader lesson is utilized to stack and cache compiled Java classes from the.zip file.
Example Plugin Directory Structure:
Bulk User Creation Plugin
This is a custom plugin built by ENH iSecure for creating Identities through SailPoint IdentityIQ and Provision the following identities to the requested Applications in IdentityIQ
A User like a manger level will have a Privilege to request for Bulk User Creation, once a .csv file is Uploaded in UI page by the following user and if the users request gets Approved a bulk number of identities will be created in Sailpoint IdentityIQ and the following identities provisioning takes place on the identities joining dates for the Requested Applications and following Email notification follows with respective action steps.
In the following video, I will be providing a detailed demo on IdentityIQ custom Plugin (Bulk User Creation)
You have to admit that there are many people who change their password to ‘incorrect’ .That way it always reminds them whenever they enter a wrong password – “your password is incorrect” . Also a survey stated more than 78% of people tend to forget their latest passwords within 21 days of inactivity .
Amidst such scenarios , securing and monitoring the access for any external users like partners, contractors and customers who have access to organizational resources have always been a challenge for many organizations thereby increasing the demand for a centralized login system. Single sign-on (SSO) is an authentication process that allows a user to access multiple applications with one set of login credentials.
Okta is the one of the leading provider for user authentication and standards-based single sign-on (SSO) for employee, partner and customer identity types. Okta supports and manages SSO for the enterprises with wide range of applications thereby providing a single secured centralized login system.
SailPoint IdentityIQ supports Single sign-on as one of its supported login configurations . The SSO is based on the SAML protocol which is a standard protocol for the SSO and other security assertions.
In this blog we are going to take a look at the integration of SailPoint IdentityIQ with Okta for Single Sign on.
The following presentation discusses in detail about the integration between SailPoint IdentityIQ and Okta.
The following is the demonstration of steps for configuring Okta as an Identity Provider for SailPoint IdentityIQ
Introduced with IdentityIQ 7.1, the plugin framework provides the infrastructure and tools to enable developers to extend the Open Identity Platform to meet a variety of specialized use cases that one might encounter in a non-standard deployment.
SailPointIdentityIQ 7.1 Plugin Framework provides a dynamic, plugin-specific class loader. It also introduces a simple, supportable, and upgrade-able user experience. The dynamic class loader provides protection for the base classes from modification, and allows for additional security and upgrade-ability.
Usually this kind of refresh is performed through UI from the debug pages in IdentityIQ. Following are the steps to follow for refreshing log4j configurations through UI.
log4j configurations whenever there are any changes have to refreshed across all the servers present in the environment. However, when a load balancer is configured, we might not have control to access individual servers through UI, thus making the refresh of log4j configurations through UI on each server.
Possible solutions:
There are 3 possible solutions for this problem.
Temporarily re-directing load-balancer traffic to only one server and refresh the configurations on the same through debug pages. This process has to be repeated across all the servers.
In an enterprise, a large number of privileged accounts are spread over various applications and systems. These accounts have higher authorizations and hence need to be handled with higher security. CyberArk‘s Privileged Account Management solution is targeted at achieving this.
In SailPointIdentityIQ, accounts can have the highest privilege in form of the ‘System Administrator’ capability. The ‘spadmin’ account that comes out-of-the-box is configured to have this privileged access. This account, if managed by the CyberArk PAM solution, improves safety of the IdentityIQ environment.
The following presentation discusses this use case and how it can be implemented using CyberArk PAM:
The following video demonstrates the use-case in action for verifying and changing spadmin password from CyberArk and initiating privileged sessions:
Email is the most powerful tool for enterprise level communication as it provides accountability and reliability in communication. To an organization, the emails that are received by the employees are a valuable resource. When an employee resigns or is terminated from the company, the organization might still need access to his/her mailbox. This is especially significant in sales, support and administration activities as it can impact the organization either directly or indirectly. This scenario can be addressed by allowing an authority within the organization to access the de-provisioned mailbox and is an important challenge within identity and access management. The risks and compliance guidelines associated with this approach are also factors that need to be considered.
Sailpoint’s IdentityIQ is shipped with a connector for Active Directory. This connector supports management of users, groups and mailboxes on Exchange server. However, for modifying the mailbox permissions, native rules need to be configured in order to execute the corresponding PowerShell scripts.
The following presentation introduces a scenario where handling mailbox permissions would be required. After an overview of native rules, the implementation of this use case is also discussed.
The following demo focuses on granting Exchange mailbox permissions via IdentityIQ and verifying that the changes are reflected on the mail server.
