Tag: Rules

SailPoint IdentityNow Rules

Posted on by Mahesh Mukku in Technology

INTRODUCTION:

  • Generally we write Rules when the required goal cannot be achieved by using transforms.
  • It is a Code based Configuration option.
  • A flexible framework that allows for very advanced or complex configurations.
  • You can just think of it as basically just writing Java code.
  • Technically it is Bean Shell however, it is much similar to Java, such that if you are familiar with Java, you will be familiar with Bean Shell.
  • Just like with transforms, the use cases drive the need for a rule and thus we have many different rule types.
  • Rules are very powerful but due to the IdentityNow architecture there are some special considerations regarding rules.
  • Essentially, rules must be very high-quality code because they are being deployed into a multi-tenant service.

Rule Execution :

There are two primary places where you can execute rules one is CLOUD EXECUTION RULE & other one is CONNECTER EXECUTION RULE .

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.

Triggering Email from PowerShell for NELM users

Posted on by Mahesh Mukku in Technology

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.

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 Implementation: Referring Rule Libraries in Validation Scripts

Posted on by Sandilya Krovvidi in Identity Governance, Sailpoint

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>