Integrating CyberArk with SailPoint using SCIM

Privileged accounts are considered to be “keys to the kingdom” in any IT Infrastructure. Almost every cyber attack that has ever happened involved compromises at the privileged account level. PAM Solutions usually help in managing such accounts, keys or files that would lead to escalated access.

CyberArk is the global leader in PAM solutions with a holistic approach towards privileged account management. It covers not only traditional PAM problems but also extends its capabilities with various features like managing hard-coded application credentials, analytics, on-demand privileges escalation and managing end-user devices like desktops.

Securing and streamlining identity and privileges data present with such solutions is of very high importance.

In the following presentation, we provide a detailed overview of CyberArk integration with SailPoint by integrating Cyberark as a SailPoint’s application.

In the following video, we provide a detailed demo of this integration.

Sailpoint IdentityIQ’s Transient workflows and their advantages

Quicklinks are usually used for faster access of specific functionalities. Often a “no delays” workflow where the start and end of the workflow happen within one single launch of quicklink shall be launched by quicklinks. Usually these kind of workflows involve custom Sailpoint forms which would not be useful once the user stops using this quick link by navigating to some other page.

Conventional workflow launches are serialized by storing the workflow cases as XML objects. This leads to many work items and workflow cases which are incomplete and hang around the Identity IQ over long run. This might lead to performance issues and unwanted data accumulated inside IIQ.

This problem could easily be solved using the transient workflows. The main feature of transient workflows is that they don’t get serialized.

Without the workflow getting serialized, we have specific advantages.

  1. Workflow cases which are inactive specific to this workflow shall not be generated.
  2. Work items that are generated do not get serialized and as a result we don’t have any unwanted work items related to this workflow in user’s inbox.

This would result in cleaner environment where we don’t have unnecessary data.

Extra perk with logging:

Workflow variables in Sailpoint are serialized in non-transient workflows. This means that we can store only the objects that Sailpoint has capability to store as XML object. Log4J loggers are very useful objects which are disqualified as workflow variables because of this restriction.

As the transient workflows do not try to serialize the objects referred by the variables, Logger objects can also be stored in the workflow variables.

This provides us the flexibility to maintain a workflow level logger variable to use your custom logging. Rather than instantiating the custom loggers whenever we require them, we can simply use the workflow variable whenever required.

Sailpoint Implementation: Referring Rule Libraries in Validation Scripts

Validation scripts are amongst the most common features while working with Sailpoint Identity IQ’s workflow forms. When we have common validation logic for multiple fields, it is always good to maintain this piece of logic in a separate rule library and call it from the validation script whenever required. This encourages modularity of the code and decreases code redundancy.

 

The way in which the name space of a validation script of a form in the workflow behaves is quite different from the rest of the workflow. Initial declaration of referenced libraries does well for referring the code in other parts of the workflow. But this does not work with validation scripts.

 

The following syntax should be used when we are using the rule referencing in validation scripts –

<ValidationScript>

<Includes>

<Reference class=”sailpoint.object.Rule” name=”Rule-Library-Name”/>

</Includes>

<Source>

// your code that calls some useful function in the rule library

</Source>

</ValidationScript>

 

 

Sailpoint – Service Now Integration

Ticketing systems form a great part of any enterprise’s IT infrastructure. Service Now is a global leader in cloud based ticketing systems and has been playing a visionary role in ITSM and ITOM.

Sailpoint integration with Service Now provides a great value when direct provisioning from Sailpoint is not possible.

It streamlines the manual provisioning by raising tickets on Service Now for provisioning. This provides a great visibility and accountability in the IT environments.

 

In the following presentation, we provide a detailed overview of Service Now integration with Sailpoint:

The following is a demo of various types of Service Now integrations that are supported by Sailpoint:

Sailpoint – Refresh Identity Cubes

In Sailpoint’s Identity IQ Refresh Identity Cubes” is one among the most important internal tasks. Refresh Identity Cubes helps in building 360 degree purview of an identity based on all the data aggregated from external sources.

The following video is an extensive discussion on various aspects of Refresh Identity Cubes.

The various aspects that are covered as part of this video are:

  1. Mechanisms to filter the identities to be considered for Refresh.
  2. Various options in the Refresh Identity Cubes.
  3. Using Multi-threading to improve the performance

 

 

 

 

Sailpoint Unix Integration

Unix is the mother of all operating systems and also is the foundation for Tim Berner Lee’s invention.

Every enterprise has a huge Unix foot print spanning across thousands of servers running various legacy applications.

As part of the mammoth task of securing the IT environments, securing the Unix servers would be the first step.

At ENH iSecure, we thrive to achieve complete and impeccable solutions leaving nothing to chance.
As a part of these efforts, we are speaking about Identity Governance in Unix with the help of Sailpoint’s IIQ.

The following is a video where we speak about governance of Unix using Sailpoint’s IIQ.

The following is a demo on Unix integration with Sailpoint.

Solving the problem with privileged ports in ODSEE instance creation

It is possible that creation of an instance in Oracle Directory Server might end up with the following error message:

port number 389 is a privileged port.

This happens because all the ports less than 1024 on Linux are treated as privileged. Most of our well know ports like 389 for the LDAP, 80 for HTTP, 443 for HTTPS reside in this range of ports.

Linux enforces that the services cannot be created at the privileged ports until and unless the privileges are escalated.

In this particular case, we can start the instance using the following command:

sudo dsadm start <path-to-instance>

The main reason for need for extra privileges when we use the privileges may be because there is a chance that the firewalls do not block traffic from these ports. Any attacker who might be interested in stealing your data over the network could be opening such ports so that he could escape firewalls. To reduce the attack surface, it is enforced that the privileged port need root access.

Using lists in Identity IQ workflows at approval steps

Sailpoint’s Identity IQ converts all the empty lists that go through an approval step in a workflow into NULL values. This does not hold the same with non-empty lists.

null diagram

For example, we have a global variable in the workflow which is an empty ArrayList ( [] ). It is going to be converted to ( NULL ) once it goes through an approval step. So in order that the lists work as per our need, we could provide a dummy value so that list is never converted to NULL when it goes through an approval.

Enabling Oracle Linux to listen for requests over the network

Oracle Linux has a default firewall in the name of package “iptables“. This firewall is enabled by default when installed .Without disabling or modifying it we could not access most of the  services provided by the Linux. For example, you may not be able to access your database and tomcat over the network.

We can disable the firewall by following the below procedure :

Firstly we need to install the iptables-services package by using following command –

sudo yum install iptables-services

Next disable the firewall by using following commands:

sudo service iptables start

sudo service iptables stop 

sudo chkconfig iptables off

To punch or block specific ports and for more information , refer to the following link.