Identity Deletion in SailPoint IdentityNow

Identity management (IDM), also known as identity and access management (IAM), ensures that authorized people and only authorized people have access to the technology resources they need to perform their job functions.

And access is managed by the user lifecycle state in IdentityNow. Identity Lifecycle State aims to automate and manage the entire digital identity lifecycle process and access throughout the organization.

Identity lifecycle is a set of stages of the identity from the creation to its deactivation or deletion. It contains a creation of an account, assignment of correct groups and permissions, setting and resetting passwords and in the end deactivation or deletion of the account.

Figure 1: Identity Lifecycle Management

Handling the unwanted identities in SailPoint increases the processing time and reduces the usability of the SailPoint tenant. To reduce the process and speed up the work, in tenant only limited and require identities we can handle, handling is easy and processing the limited identities is a less time-consuming process, so we can delete unwanted and terminated users’ identities from SailPoint.

Now, let us have a look at the SailPoint REST API’s used in the Identity deletion process. Below is the list of APIs used for Identity deletion in SailPoint IdentityNow:

Figure 2:  REST APIs in PowerShell Script connecting with SailPoint IdentityNow

And here, we will be using A personal access token (PAT) is a method of authenticating to an API as a user without providing a username and password.

Prerequisites for Identity deletion:

  1. SailPoint REST API’s.
  2. Client ID and Client Secret.
  3. IQservice Server.

Now, let us discuss the use case of Identity deletion.

Use Case:

All the identities in the “30daysPostTermination” lifecycle state will be deleted from IdentityNow. 

The deleted identities would be re-aggregated in the next aggregation cycle as “Uncorrelated accounts” in target application, and hence would not affect the new hire creation logic and the SAMAccount name would remain unique as per the requirement and the logic defined.

A PowerShell script will be developed to call the APIs to identify all the Identities in the required lifecycle state i.e. “30daysPostTermination” and will delete the accounts from the HRMS Source for all the Identities.

Figure 3: Use Case diagram.

Steps Overview as per the script:

Step1: As part of the PowerShell script first it will read the require details from property file. In property file we can maintain the ClientID, client Secret, base URL, search query, deletion limit, log file path and debug values.

Step2: Authentication API will execute to generate the access token.

Step3: Next Search API will execute and the fetch “30daysPostTermination” lifecycle state identities from SailPoint Tenant.

Step4: One by one Identities will pass to Delete API to delete from SailPoint Tenant.

Let us understand Identity Deletion by using SailPoint REST APIs, use cases and automation of the script via windows task scheduler in the following below presentation:

Advantages of Identities Deletion in SailPoint IdentityNow.

  1. It will increase the usability of the tenant.
  2. It decreases the aggregation and identity refresh process time.
  3. It will fasten the backend processes and reduce the unwanted identity handling.
  4. Reduce the burden on the tenant.

When a user got terminated or left the organization, all access will be removed, and accounts will be disabled.
Now, let us go through a demo on how we can achieve identity deletion in SailPoint IdentityNow.

Triggering Email from PowerShell for NELM users

Introduction

This blog is intended to demonstrate on automating email notifications for newly on-boarded contractors from IdentityNow. This will help in sending auto email notifications to users & their managers (if required) to reset their first password. This is enabled by running a PowerShell script in a shared folder in the IQ Service Server. In the current process, the IT help desk team needs to reach out to the user for his first login. With the help of PowerShell script, this process can be automated by sharing the password reset link automatically.

Use Case Diagram

The above diagram depicts the overall process flow of the use case with the point of initiation being the IQ Service Server following with the SMTP server.

  • Current IdentityNow templates don’t have email notification which will send Email ID ,password reset link and user manual to end user on his first day to instantly. To achieve this requirement, we have written PowerShell script and rule to achieve desired requirement above diagram gives the overview of how we have achieved this requirement.
  • From UI Request center, HR or Manager will request for an AD account depending on the license to be assigned for the user to be on-boarded.
  • Once request is completed Active Directory account will be created and the After create rule will be triggered.  By using this rule, we are triggering PowerShell script which is placed in IQ service server for sending Email by using SMTP server containing Email Id, Password reset link & user manual. We can also edit the contents to be shared in the email based on the organization requirements.

Detailed discussion on the overall Use case, communication flow and the advantages:

Introduction to IQ Service Server

  • The IQ Service, also known as the Integration Service, is a native Windows service that allows Identity Now to participate in a Windows environment and access information that is only accessible via Windows APIs.
  • It is a lightweight service that must be installed on any supported Windows Server that has connectivity to the target systems you want to manage in Identity Now.
  • It also secures all incoming & outgoing communications of the server. Overall security of the solution and data integrity will be ensured even in crucial stage.
  • We can create several instances on the same machine as per the system requirements.
  • This server is primarily responsible for provisioning in AD from IdentityNow.

IQ Service Communication Flow

  • IdentityNow always push task to a VA cluster queue and from cluster queue, VA will pull the request based on the priority of task.
  • Once request is fetched by VA, VA will communicate to IQService for tasks such as aggregation, create and modify the accounts.
  • IQService server communicates with domain controller using LDAP/LDAPS.
  • IQService receives the data from domain controller and gives it back to VA (Outbound traffic).
  •  Finally VA will give the updated results to the tenant and requests for the new task.

Rule Execution process in IdentityNow

Rule execution can be executed in 2 primary places:

  • Cloud Execution – These rules are executed in the IDN multi-tenant cloud.
  • Connector Execution – These rules are executed on the on-premise IDN virtual appliance.
  • Connector Rules are rules that are executed in the IdentityNow virtual appliance, and they are usually extensions of the connector itself. The rules are particular to only certain connectors since they are frequently applied to carry out complex connector-related tasks. Because these rules function within the virtual appliance, they are unable to access IdentityNow’s data model or collect data from it.
  • The basic logic required to initiate a PowerShell script is derived from the after-creation rule, which then transfers the majority of the subsequent events and/or modifications to the PowerShell script itself. Since this script would be stored on the client’s servers, the customer could easily modify it as needed. Since the code runs outside of the IdentityNow platform, it allows the client to add updates to the PowerShell scripted functionality without requiring SailPoint to review the code.

Demonstration of the use case in IdentityNow

Use of Powershell script in IdentityNow

  • The popularity of scripting languages with Object Oriented capabilities—like PowerShell is because of their simplicity and use.
  • These languages’ native scripts can access request and result objects more quickly and effectively.
  • The Utils.dll class library that is bundled with the IQ Service contains all the necessary classes to access the request and result objects. Process environment variables would be presented as inputs to the script.
  • The environment variables contain XML-based data. Using Utils.dll, the script creates the appropriate objects.
  • Once the object is modified, the script should execute the object’s xml() function to convert it to XML and then send the XML to the path mentioned in the script’s single argument.
  • In the event of an error, the script generates a non-zero value and logs the message in the appropriate file at the specified directory.

Before/ After Scripts for IQ Service

  • The IQ Service allows function customization by allowing the integration of before/after scripts developed using scripting languages such as PowerShell.
  • Any required tasks that cannot be automated with the current source functionalities can be automated with scripts.
  • Native before scripts are scripts that are called before the request is processed; native after scripts are scripts that are called after the request is processed.

The following sources support Before/After Scripts for IQ Service:

Advantages

  • It will helps end user to get his organization email ID, password Reset Link & User manual for SailPoint as IdentityNow Default email templates don’t have this type of functionality.
  • We can set a customized template and add an initial login guide or any policy documents as an attachments while triggering this email.
  • The dependency on IT help desk team for sharing login details for the newly on-boarded contractors is reduced to a huge extent.
  • Contractors can login to their system almost immediately post completion of the on-boarding without having any downtime.

Oracle Fusion Integration with SailPoint IdentityIQ

About Oracle Fusion: Oracle Fusion Cloud HCM is a complete cloud solution that connects every human resource process and every person across the enterprise.

Benefits of Oracle Fusion:

  • Oracle HCM cloud enables HR leaders by delivering an end-to-end solution to manage every stage of the employee lifecycle.
  • Human capital management transforms the traditional administrative functions of human resource departments – recruiting, training, payroll, compensation, and performance management into opportunities to drive engagement, productivity, and business value.
  • It also offers Data Efficiency by preserving history of changes made to the attributes of some objects. As a Professional user, you can retrieve and edit past and future versions of an object.
  • Many HCM objects, including person names, assignments, benefits-plans, grades, jobs, locations, payrolls, and positions are date-effective. Date-effective objects include one or more physical records. Each record has effective start and end dates. One record is current and available to transactions. Others are past or take effect in the future. Together, these records constitute the logical record or object instance.

Integration with SailPoint IdentityIQ

Here, Oracle Fusion application is integrated with SailPoint using Webservices connector. Let us have a quick overview of basic configuration parameters of SailPoint IdentityIQ Webservices Connector

Webservices connector application configuration
  • Base URL: The base URL is used to connect to the web service managed system.
  • Authentication Method: Authentication methods that is supported are: OAuth2, API Token, Basic Authentication and No/Custom Authentication
  • Schema Attribute for Account Enable status: Attribute name and value required to be provided to check the Enable status. For example: status=Active
  • Username: Username of the resource owner
  • Password: Password of the resource owner
  • Grant Type: We can select the type of Grant from below: Refresh Token, JWT, Client Credentials, Password and SAML Bearer Assertion
  • Client Id: (Optional for JWT and SAML Bearer Assertion) Client Id for OAuth2 authentication.
  • Client Secret: (Optional for JWT and SAML Bearer Assertion) Client Secret for OAuth2 authentication.
  • Token URL: URL for generating access token.

Basically, connecting SailPoint to your Web Services allows you to configure any web service supported managed system which can read and write on the managed system using the respective managed system’s Web Services. Web Services supports JSON and XML for read and write.

Oracle Fusion Integration with SailPoint IdentityIQ

Now, let us have a look at the Oracle Fusion REST APIs used in the Integration process. Below is the list of APIs used for integrating Oracle Fusion to SailPoint:

  • Get all Workers API: This fetches all the worker records as of the specified date. Worker types include employee, contingent worker, and pending worker. By default, the current date is retained.
  • Get all User Accounts API: This fetches all the userAccounts. We may need to manage user accounts for the workers to assign or revoke Fusion Roles
  • Get all Roles API: This is used the get the roles assigned to the user accounts.
  • Create Employee API: This is used to create an Employee record in Oracle Fusion.
  • Update Employee API: This is used to update an Employee record in Oracle Fusion.
  • Terminate Worker API: This is used to Disable a Worker record in Oracle Fusion.
  • Role Revoke API: This is used to revoke an assigned role.
  • Rehire Employee API: This is used to Enable an Employee record in Oracle Fusion.

And here, we will be using Basic Authentication in the Integration Process where we have used Username and Password of the resource owner to from connection between Oracle Fusion and SailPoint IdentityIQ

Prerequisites for integrating Oracle Fusion with SailPoint

  1. Oracle Fusion REST APIs
  2. Oracle Fusion instance
  3. Base URL of the Oracle Fusion instance
  4. As we are using Basic Authentication, we need username and password for the APIs

Now, let us discuss the use cases involved in the integration process.

Use Cases

1. Joiner/Create account Process

Joiner Process starts with the creation of account in Truth Source application. Then that account will be brought to SailPoint through a scheduled aggregation task.

Joiner/Create Account Process

Then through a Scheduled Refresh Identity Cube task and using a configured Business Role and Assignment Rule, two conditions are checked.

  1. Identity or Account in Truth Source is Active
  2. Business Unit is XXXX

If these two conditions are satisfied. Then the account creation process for Oracle Fusion application gets triggered. As part of the Joiner or Account creation process, Basic access will be provisioned to the newly created account from the Fusion end automatically.

2. Leaver/Disable Account Process:

Leaver process starts when the Last working day attribute of account is populated in Truth Source application.

Leaver/Disable Account Process

Then that Last working day for that account will be updated in SailPoint through a scheduled aggregation task. Then through a Scheduled Refresh Identity Cube task, it is checked that if that Last working day is equal to Today’s date. In other words, it is checked that if the Last working day has reached.

If the Last working day has reached, then the account disable process for Oracle Fusion application gets triggered.

As part of the Termination process, all the Roles which that account has, will be de-provisioned.

3. Rehire/Enable Account Process:

Rehire Process starts by enabling the account in Truth Source application. Then that is updated in SailPoint through a scheduled aggregation task.

Rehire/Enable Account Process

Then through a Scheduled Refresh Identity Cube task, the account enable process for Oracle Fusion application gets triggered.

As part of the Rehire/Enable account process, another new Assignment is created for that account with AssignmentName and AssignmentNumber appended with “R”. And Basic access will be assigned to that enabled account as we saw in the create account use case.

Advantages of Integrating Oracle Fusion with Sailpoint IdentityIQ:

  1. In this integration, we have automated the creation of account in Oracle Fusion. Whereas before the integration, Oracle Fusion team had to create an account in Oracle Fusion manually for the new Joiners
  2. In this integration, we have also automated the Disabling and Role Revoke operations. Actually, when the Last Working Date of the user has reached, then the Oracle Fusion account of this leaver will be disabled and Oracle Fusion Roles assigned to this leaver will Revoked, by Sailpoint. Whereas, before the integration, Oracle Fusion team had to disable the account and Revoked Roles in Oracle Fusion manually for the leavers.
  3. In this Integration, we have also automated the update operation as well. From Sailpoint, we are updating the attributes such as LegalEmployerName, Department, Job, Grade, FirstName, LastName, DisplayName, etc. Whereas, before the integration, Oracle Fusion team had to handle these updates manually which will be a tedious task to do.
  4. We have also automated the Rehire Process. When a user got rehired, then for that user, Oracle Fusion account will be enabled and a new work relationship will be created from Sailpoint.

When a user got Rehired, only the Basic access will be given, not the access that user had before Leaver process for that user initiated.
The detailed discussion of Oracle Fusion introduction, Oracle Fusion TEST APIs, use cases and integration approach is discussed in the following video:

Now, let us a have a demo on integration of Oracle Fusion with SailPoint IdentityIQ in the following video:

SAP SuccessFactors Integration with SailPoint IdentityNow

SAP SuccessFactors integration with  SailPoint IdentityNow.

SuccessFactors is an SAP product suite to provide cloud-based solution to manage business alignment, people performance, recruitment, and employee central and learning activities for all sizes of organizations.

SAP SuccessFactors is cloud based HCM solution and is designed on Software as a Service (SaaS) cloud model. Software as a Service is also known as On-demand software solution where software is licensed on a subscription basis and is centrally hosted.

SaaS has become a common delivery model for many business applications, including office and messaging software, payroll processing software, DBMS software, management software, CAD software, development software, gamification, virtualization, accounting, collaboration, customer relationship management (CRM), management information systems (MIS), enterprise resource planning (ERP), invoicing, human resource management (HRM), talent acquisition management and other software and infrastructure services.

  • In SaaS, software and application data is hosted on a remote cloud and can be accessed on demand from any location using secured login credentials.
  • SaaS software is multitenant that allows many instances of the software to be accessed and are on the same application version.
  • Users have an option to select features and functionality to use in the standard solution and in the regular releases that are introduced by the vendor.
  • SaaS Solution is based on multitenant architecture where a single configuration is applied for all the tenants or customers. To provide scalability, you install application on multiple machines.

IdentityNow SAP SuccessFactors connector supports Account Management for loading accounts, delta aggregation and Provisioning.

SAP SuccessFactors integration with SailPoint IdentityNow Blog

Pre-requisite

At-least Virtual Appliance need to be configured in order to have communication between IdentityNow cloud and SAP source however SailPoint recommends to have 2 virtual appliances in cluster.

Permissions required :

•Test connection : To test the connectivity from IDN cloud to SAP SuccessFactors source.

•Account Aggregation : To aggregate account details to IDN cloud.

•To perform connection tasks, must have the following permissions:

a. SFAPI User Login

b. Employee Central HRIS SOAP API

•For example, The Success Factor source aggregates the employee data from the SuccessFactors managed system based on the Picklist configuration which is a configurable set of options or selection lists used to populate a data input field with one of a number of predefined values in the Success Factors that can be obtained.

Next for aggregation we required the following permission:

  • Manage User : Employee Export
  • Metadata Framework : Admin access to MDF OData API
  • Manage System Properties : Picklist Management and Picklists Mappings Setup
  • Employee Central API : Employee Central Foundation OData API (read-only), Employee Central HRIS OData API (read-only), Manage Role-Based Permission Access

Let us see prerequisites for SAP SF integration.

•For configuring the base URL for IdentityNow tenant we need to configure data center wise.

•The base url will vary from datacentre to datacentre.

•In the blog we have provided the link for SuccessFactors API URLs for different Datacenters.

https://userapps.support.sap.com/sap/support/knowledge/E/2215682

SAP SuccessFactors integration with SailPoint IdentityNow Demo

DocuSign Integration with SailPoint

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

  1. Need to get the DocuSign API details for the different operation.
  2. Base URL will be different for different environment.
  3. secret key and client ID for the token generation.
  4. Generating access token with Authorization code.

Use Cases

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.

Sailpoint IdentityIQ: Bulk User Creation Plugin

Bulk User Creation Plugin in IdentityIQ

Introduction

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.

Developing Plugins

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)

SAP HR & ECC Source Integration

SAP is one of the world’s leading producers of software for the management of business processes, developing solutions that facilitate effective data processing and information flow across organizations.

SAP software provides multiple business functions with a single view to the entire data. This helps companies better manage complex business processes by giving employees of different departments easy access to real-time insights across the enterprise.

SAP solutions are classified into 6 core products as listed below.

In the below video, we are going to see the SAP HR/HCM source and SAP ERP Core Component (ECC) source integration in SailPoint IdentityNow.

SAP HR system integration.

SAP HCM solution is used to streamline the HR process and create a people centric organization.

SAP HR/HCM system that we are integrating in SailPoint IdentityNow will be the truth source from which identity governance is managed.

SAP ECC system integration

SAP ECC is the ERP system that integrates information from one SAP system to another system in real time, this helps companies better manage complex business processes by giving employees of different departments easy access to real-time insights across the enterprise.

As a result, businesses can accelerate workflows, improve operational efficiency and raise productivity.

By integrating SAP ECC to SailPoint IdentityNow, Identity access management and governance will be simplified.

Use cases.

On demand access request: User can request access based on requirement from request center.

Separation of Duties: Whenever user request for conflicting access SoD policy violation check will happen and warn the approver that approving access will violate SoD policy.

Leaver Scenario: When user lifecycle state is changed to terminated the end target applications access will be disabled.

Certification campaign: To certify user is having right access certification campaign can be configured and can be certified by user’s manager or source owner or a specific individual.

In the below video, we are going to look at a demo of above specified integrations and use cases.

Event Triggers

Event triggers is an extensibility feature recently released by sailpoint which enables us to integrate identitynow with third party applications. Event triggers follows an event based architecture towards integration.

IdentityNow has many even triggers which capture the events internal to IdentityNow. This can be related to various IdentityNow internal processes like aggregation, provisioning, access request etc.

In response or action to an event, Event triggers have a capability to communicate with external applications. This response can happen via webhooks or AWS event bridge.

If webhook is configured as an action for the event trigger, respective HTTP APIs will be called.

If an AWS event bridge is configured for the event trigger, an event can be setup to be captured on an AWS event bridge.

Types of Event Triggers

REQUEST_RESPONSE

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.

FIRE_AND_FORGET

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.

IdentityNow has a set of event triggers that you can configure to connect to web hooks in third-party systems.

Available Event Triggers

In below presentation we will be viewing the concept of event triggers in brief.

Use Case:

Let us see a real time use case for this.

Below is the workflow representation.

In below video we will be demonstrating the real time implementation of event triggers.

References:

https://developer.sailpoint.com/triggers/getting_started.html

Segments Image

SailPoint IdentityNow : Segments Feature

Introduction

Access requests is a feature in SailPoint IdentityNow using which the users gain ability to make a manual request for access that they need.

Segments feature released by SailPoint IdentityNow is  promoting zero trust in the enterprises. Using this feature, request center items will be made available to the users only on a “Need to know” basis.

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 :

Advantages

  1. 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.
  2. 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.  
  3. 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.
  4. 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.

References

TopicURL
Segments Documentationhttps://documentation.sailpoint.com/saas/help/requests/segments.html?h=segmen
Segments REST API referencehttps://developer.sailpoint.com/apis/beta/#tag/Segments

SailPoint IdentityNow: Connector Rule API’s

Extensibility of services using vast API collections is sign of a true SaaS solution. SailPoint IdentityNow has recently released few APIs which allow us to upload our own connector rules required for app integrations.

Rule

In IdentityNow, Rules are the configurations which are used to provide additional flexibility where needed. Rules are basically developed using a scripting language called Bean Shell, it is a lightweight scripting language whose syntax is similar to Java.

Based on Execution type rules are divided into two types:

Cloud ExecutionConnector Execution
1)The Rules which are executed in the IDN tenant cloud are called Cloud Execution Rules.
1)The Rules which are executed on virtual Appliance (on premise) are called Connector Execution Rules.
2)There will be a review process for cloud rules to ensure any submitted Cloud Rules meet SailPoint requirements and doesn’t contain code that could harm the system and the only way to upload the rule is through SailPoint.2)Connector Rules are usually extension of the connector itself. These rules are mainly used to implement pre-processing of data and post-processing of data and to manipulate, merge or otherwise transform the incoming data as it’s being read

Rule Deployment Process

As-Is Process

In As-Is Process for deploying Connector Rules on the tenant developer should follow the below steps:

  1. Rule needs to be developed as per the requirements.
  2. Developed rule shall be submitted to SailPoint Expert services for review.
  3. Post review, rule will be uploaded on to the tenant.
  4. In case of any changes required the rule shall be resubmitted to the SailPoint Expert Services.

To-Be Process

In To-Be process the rule can directly be deployed to the IDN tenant using APIs. In case of any changes required/delete the developer can directly use these APIs and make required changes instead of going through tedious process like earlier.

Advantages and Limitations

Advantages

  1. Easy to Deploy – They are Easy to deploy on to the tenant compared to the entire previous process
  2. Faster deployment of rules – Rules will be deployed on the tenant instantly using APIs where old process used to take a minimum of 24hrs
  3. Low Cost from SailPoint Expert Services – Compare to previous methodology, deploying connector rules using APIs has minimal involvement from Expert Services.
  4. Rework is Faster – In case of any changes rather than repeating the entire process, rework is quicker using these APIs.
  5. Faster Integrations – Using APIs, the overall application integrations are faster.

Limitations

The only limitations for these APIs are that these APIs support only connector rule types, but not for the cloud rules as of now.

Connector Rule Rest API Operations

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.

Detailed documentation on connector rules APIs can be found here:

https://developer.sailpoint.com/apis/beta/#tag/Connector-Rule-Management

In the following presentation, I will be providing a detailed overview of Rules and Connector Rule APIs

In the following video, I will be providing a detailed demo of the Connector Rule APIs and their operations