SAP SuccessFactors Integration with SailPoint IdentityNow

Posted on by Suraj Bharat Gorle in Technology

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

Posted on by abhishek darekar in Technology

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

Posted on by Dineshwar Manukonda in Identity Governance, Sailpoint, Technology

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

Posted on by Aditya Veldi in Identity Governance, Sailpoint, Technology

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

Posted on by Abhinov Dhonthula in Identity Governance, Sailpoint, Technology

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

Posted on by Arshad Moghul in Identity Governance, Sailpoint, Technology

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

Posted on by Yathish Ponnana in Identity Governance, Sailpoint, Technology

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

Sailpoint IdentityIQ: IdentityIQ Aggregation Using Multi Threading and target resource mapping

Posted on by Akhil Kondapalli in Technology

Aggregation Using Multi Threading:

Introduction:

SailPoint IdentityIQ supports partitioning of various jobs so that data processing can not only be split across multiple hosts but also across multiple threads per host. The overall goal with partitioning is to increase processing throughput and speed. Specifically, partitioning is supported for account aggregation tasks, for identity refresh tasks, for generation of manager certifications, and for role propagation. This blog describes the steps required to configure partitioning for account aggregation tasks and Target resource mapping.

In the following presentation, I will be providing a brief introduction of IdentityIQ Aggregation Using Multi Threading and target resource mapping

Partitioning Settings:

The Server, ServiceDefinition, and RequestDefinition objects defined for the installation specify important parameters that affect partitioning.

Server Object:

SailPoint IdentityIQ automatically creates a Server object for each host which connects to an IdentityIQ database. A maxRequestThreads value can be specified in the Server object’s attributes map to designate the maximum number of threads which can be used for request processing on this host at one time.

If your installation uses maxRequestThreads settings per Server object, the recommendation is to set the maxRequestThreads value equal to two times the number of CPUs on the server (e.g. 4 CPU means value of 8).

Service Definition Object:

By default, each IdentityIQ host as part of an installation serves in UI, task, and request roles simultaneously. By default, the hosts attribute is set to global for Task and Request ServiceDefinition objects, meaning all connected IdentityIQ hosts function as Request and Task hosts. The CSV delimited list of host names in the hosts attribute must be set to the same value returned by the hostname command when it is run on the application server hosts.

RequestDefinition Object:

RequestDefinition objects govern how IdentityIQ handles items added to the Request queue for processing. Each RequestDefinition object specifies the maximum number of threads per server to use for each request type through its maxThreads attribute. The maxThreads values on each of these mentioned RequestDefinition objects govern the number of threads that IdentityIQ will attempt to use on each request server to run each task of the specified type. 

The recommended best practice is to specify a value for maxThreads in the range of 1-2 times the number of CPUs for all RequestDefinition objects mentioned here. It is strongly recommended that all request/task servers in an IdentityIQ installation have the same number of CPUs, available memory, and allocated disk space.

Aggregation Task Configuration:

Activating partitioning on an aggregation task is simple once other partitioning settings are configured. It only requires selecting the Enable Partitioning option in the task definition user interface page. This must be enabled for each aggregation task which will use partitioning, as this setting is disabled by default. There is a second configuration option for TaskDefinitions that is applicable in some situations: objects per partition. This option sets the maximum number of records to include in each partition. IdentityIQ will then divide the accounts from the data source into as many partitions as required.

Target Resource Mapping:

In sailpoint identityiq Target Resource mapping is used to reflect the changes in target application based on the source application.

Source and Target Mapping Configuration:

The source mappings is used for the attributes coming in from target to IIQ. For ex., you may define a source mapping for status attribute as “employeeStatus”. This attribute can then be used by SailPoint for all internal processing.

The target mappings is used for provisioning the updated values of attributes to target from IIQ. Assume, you have defined source mapping “employeeStatus” coming from HR application and if you wish to populate this value to AD, the target mappings can be utilized.

Refresh Identity Cube Task Configuration:

In Refresh Identity Cube task we have an field which is Synchronize attribute.

After checking that field the identity mappings target will be provisioned if there are any changes in source application

In the following video, I will be providing a detailed demo on IdentityIQ Aggregation Using Multi Threading

SailPoint IdentityNow: Extensibility Feature Integration for Access Requests

Posted on by Arshad Moghul in Identity Governance, Sailpoint, Technology

Each progressing year, IT is getting more and more complex. Organizations keep growing and subsequently more and more people come into the organization each with their own needs. These users are then provided with their own levels of access to resources. The problem that arises here is that the growing mess of systems and user access management.

IdentityNow is an IDaaS (Identity as a Service) based IAM solution, unlike IdentityIQ which is on-premise. IdentityNow also helps people get the access that they need and manage the lifecycle around it. The current blog discusses the extensibility features announced by SailPoint. These features will help make security decisions on the go very effectively.

In the following presentation, I will be providing a detailed overview of Extensibility Feature Integration with IdentityNow for Access Requests.

Overview of Extensibility Features :

Users at an enterprise level are distributed among different geographies of the world. SailPoint’s access request integration with applications such as Microsoft Teams and Slack enable the users to get the access that they need right from the tool that they use the most. SailPoint also ensures that the appropriate governance and compliance controls are enforced while providing ease of access to the users while making access requests.

Current Access Request Process :

To briefly understand the current access request process in IdentityNow below is an illustrative diagram:

Roles in IdentityNow combine provisioning to multiple sources by combining different access profiles. However, for access requests, roles can be marked as “requestable”. By doing this, the roles are then visible in the Request Center tab in IdentityNow. We can have approvals in place for this role such that any user who requests for this role, will by routed through an approval process.

Applications in IdentityNow have their own XML structure with their own password policies and account creation restrictions. For the approvals, we can define the approval hierarchy in Access Profiles itself. Once the application has been created, it should be marked as ‘visible in request center’ and ‘allow access requests’.

Users have to login to their IdentityNow tenant with their credentials. They navigate to Request Center tab to see “Applications” and “Roles” where they can make an access request from either of these. Both Roles and Applications facilitate provisioning to the target source using Access Profiles.

Applications and Integration Overview :

  1. Microsoft Teams

Microsoft teams is a chat-based collaboration platform from Microsoft. With capabilities such as documents sharing, online meetings, teams and channels, online video calling and screen sharing, messaging and many more extensible features for business communication. It is extremely user friendly and can facilitate a work environment between remote users and large businesses. Below are the benefits from this integration:

  • Ease of making access requests from within the Teams Application.
  • Users can request either for a Role or Application depending on the business needs.
  • This integration ensures seamless user experience for making access requests.

Below is the process followed post the integration with MS Teams:

  • Users will login to their Teams application using their Office365 account.
  • A SailPoint chatbot is configured which appears in the Applications tab.
  • Connect to your IdentityNow tenant and click on “Create Access Request”.
  • Find and select the Application/Role to request.
  • Select the role for himself or for others.
  • Submit the request.

2. Slack

Slack is workspace alternative communication tool just like teams which combines the functionalities for messaging, tools and files. Users can communicate over channels or Direct Messages based on their requirement and it has support for third-party application integrations and add-ins. Although the application is free to use with certain limitations, there is an enterprise level application as well. Below are the benefits from this integration:

  • Ease of making access requests from within the Slack Application.
  • Users can request either for a Role or Application depending on the business need.
  • This integration ensures seamless user experience for making access requests.

Below is the process followed post the integration with Slack:

  • A user will login to their Slack application using their work email and authenticating from it.
  • A SailPoint chatbot is configured which appears in the Applications tab.
  • Connect to your IdentityNow tenant and click on “Create Access Request” by entering a forward slash in the SailPoint’s chatbot.
  • Find and select the Application/Role to request.
  • Select the role for himself or for others.
  • Submit the request.

Access Request : From an API perspective

  • This integration is achieved using REST API’s. REST stands for Representational State Transfer.
  • It is an architectural style for the web services.
  • This architectural style helps in lesser use of bandwidth to make an application more suitable to communicate over the internet.
  • It is often regarded as the language of the internet.
  • The primary methods that the REST APIs communicate are
    • Create – POST
    • Read – GET
    • Update – PUT/PATCH
    • Delete – DELETE
  • SailPoint has developed the REST API’s for IdentityNow. The reference documentation is available at developer.sailpoint.com
  • Please note that the {api-url} below is the org name of your IdentityNow tenant.
  • The primary APIs that are used behind this integration are:
    • List of access request objects: Returns a list of requestable items for an access request.
      • GET – https://{api-url}.api.identitynow.com/v3/requestable-objects
    • Create an access request: Submits an access request to IdentityNow. This will not return any result because the request has been submitted by the system. If there are more than one identity for the access request, the JSON payload will contain a list of id’s for each identity.
      • POST – https://{api-url}.api.sailpoint.com/v3/access-requests
    • Get the access-request status: Returns a list of access request statuses based on the specified query parameters.
      • GET – https://{api-url}.api.identitynow.com/beta/access-request-status

In the following video, I will be providing a detailed demo of the access request integration with Teams and Slack.

Sailpoint IdentityIQ: Object Exporter Script

Posted on by Pavan Chappidi in Identity Governance, Sailpoint, Technology

Introduction:

SailPoint IdentityIQ is a J2EE Application that is built on top of Hibernate object-relational model. All the Dev Artifacts are Java Objects represented in XML. The current blog discusses the script which helps in

  1. Migrating Artifacts to higher environments
  2. Migrating standard libraries

Working:

Below are the steps describing working of the script:

  1. The script will export objects from one IdentityIQ Environment through console attached to the instance (Console is a command line utility to each identityIQ instance provided).
  2. Script will perform necessary processing on the exported objects and prepares to be imported to the Target Environment.
  3. The Objects will be imported into the Target Environment through console attached to the instance.

Usage:

  1. Configure the Config.xml file provided with the following parameters
    1. Export Console Path
    2. Import Console Path
    3. Required Objects
  2. Run the script provided.

Below is the Demo on Exporter script: