Uncategorized Archives - IdAM Thoughts

As you may know, for IdentityNow Cloud Rules – they have to be submitted to SailPoint for upload to the tenant. We have a rule validator tool to validate IdentityNow rules for malformed or incorrect code fragments, and help make sure they conform to the SailPoint IdentityNow Rule Guide before rule submission.

We have had a great release of a brand new IdentityNow Rule Validator v3.0 (currently sitting on 3.0.23 at the time of writing). This is a major jump forward with mention in release notes (many more enhancements than what it states 🙂 )

BeanShell linter will now validate syntax and usage to help discover issues in your code before you deploy
A watch option which continually monitors and validate/lint your code while you develop.

Download: https://community.sailpoint.com/t5/Professional-Services/IdentityNow-Rule-Validator/ta-p/166116

Please download and use the latest one when submitting rules for deployment otherwise you rule will get rejected for using the old version.

What I wanted to point out was that Generic Rules may start failing validation as it is doing much strict linting check for variables coming from transform which are not defined in the rule. You will need to add them to <Signature> tag for it to now pass validator.

Example

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Rule language="beanshell" name="Example Rule">
	<Description></Description>
	<Source><![CDATA[

		import org.apache.commons.lang.StringUtils;

		String identityName = identity.getName();
		String endDateStr = StringUtils.trimToNull(identityEndDate); // identityEndDate will be passed in from a transform

	]]></Source>
</Rule>

<?xml version='1.0' encoding='UTF-8'?>

<!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd">

<Source><![CDATA[

import org.apache.commons.lang.StringUtils;

String identityName = identity.getName();

String endDateStr = StringUtils.trimToNull(identityEndDate); // identityEndDate will be passed in from a transform

]]></Source>

</Rule>

You will see two inputs

identity – this is the identity context which every cloud rule has access to but not predefined as input in the Generic Rule type.
identityEndDate – this is an input coming from a transform which is calling the rule

If I run this on the rule validator, it will fail with the following errors

Errors: (2)

  Line 5 - [LintBSHMethodInvocation(93)] null Exception: Could not retrieve definition for variable name 'identity'
    5: String identityName = identity .getName ( )


    Variables may be injected by IDN, these variables can be injected into the rule by modifying the Rule's XML Signature, Add an Argument to the Input Section.  Example adding a variable 'academicLevel':
    <Inputs>
      <Argument name="academicLevel" type="java.lang.String"...

  Line 6 - [LintBSHAmbiguousName(69)] null Exception: Could not retrieve definition for variable name 'identityEndDate'
    6: String endDateStr = StringUtils .trimToNull ( identityEndDate )


Validation status: FAILURE

Errors: (2)

Line 5 - [LintBSHMethodInvocation(93)] null Exception: Could not retrieve definition for variable name 'identity'

5: String identityName = identity .getName ( )

Variables may be injected by IDN, these variables can be injected into the rule by modifying the Rule's XML Signature, Add an Argument to the Input Section. Example adding a variable 'academicLevel':

<Argument name="academicLevel" type="java.lang.String"...

Line 6 - [LintBSHAmbiguousName(69)] null Exception: Could not retrieve definition for variable name 'identityEndDate'

6: String endDateStr = StringUtils .trimToNull ( identityEndDate )

Validation status: FAILURE

As you can see – it couldn’t retrieve the definition for both the attributes

Solution

You need to define them under the Signature XML tag so that the validator allows it through

<Signature returnType="Object">
    <Inputs>
        <Argument name="identity" type="sailpoint.object.Identity">
            <Description>Get Identity Object</Description>
        </Argument>
        <Argument name="identityEndDate" type="java.lang.String">
            <Description>EndDate coming from Transform</Description>
        </Argument>
    </Inputs>
</Signature>

<Description>Get Identity Object</Description>

</Argument>

<Description>EndDate coming from Transform</Description>

</Argument>

</Inputs>

</Signature>

As you can see the Signature tag is defined with Argument name and type. This will allow the rule validator to understand what they are. So the rule will now look like

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Rule language="beanshell" name="Example Rule">
	<Description></Description>
		<Signature returnType="Object">
		<Inputs>
			<Argument name="identity" type="sailpoint.object.Identity">
				<Description>Get Identity Object</Description>
			</Argument>
			<Argument name="identityEndDate" type="java.lang.String">
				<Description>EndDate coming from Transform</Description>
			</Argument>
		</Inputs>
	</Signature>
	<Source><![CDATA[

		import org.apache.commons.lang.StringUtils;

		String identityName = identity.getName();
		String endDateStr = StringUtils.trimToNull(identityEndDate); // identityEndDate will be passed in from a transform

	]]>	</Source>
</Rule>

<?xml version='1.0' encoding='UTF-8'?>

<!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd">

<Description>Get Identity Object</Description>

</Argument>

<Description>EndDate coming from Transform</Description>

</Argument>

</Inputs>

</Signature>

<Source><![CDATA[

import org.apache.commons.lang.StringUtils;

String identityName = identity.getName();

String endDateStr = StringUtils.trimToNull(identityEndDate); // identityEndDate will be passed in from a transform

]]> </Source>

</Rule>

Now the rule will pass

No errors found.

Validation status: SUCCESS

No errors found.

Validation status: SUCCESS

You are good to submit your rule now…

Happy coding!!!

This has been long time coming and an ask from many clients. We wanted to have a UI interface to be able to create non employees like contractors etc directly inside IDN (as a source). These type of records might not generally come from an HR source and are maintained directly in AD or other such places. Thus, we have got a new type of source called NELM (Non Employee Lifecycle Management) which has a UI interface where you can enter them.

Currently its a two step release focusing on API based release happening over the weekend in the production orgs (already in your sandbox). Read more about it in this article.

You can

Have multiple sources – how about designing each via type like service account, contractors or say via departments?
Approver for each creation – as above you can assign approvers per type or department and segregate.
Custom schema as per your liking
Manage these users as normal LCS and business rules like any other source.

Note: There is currently a launch limit of 20 NELM sources per org and 1000 identities per source. Also up-to 10 custom schema attributes. So take that into consideration of your design. I would see this lifted or eased in future as this is used more by customers.

Here is a screenshot of how it looks while creating a user for the source.

A lot is currently via API but in a few months we will have more coming in UI.

You should start testing and possibly convert your csv sources and manual uploads of such users to a nice UI interface with better auditing and management.

Let me know if any questions.

Edit: Documentation is live!!!

Uncategorized

Guides

IdentityNow Rule Validator 3.0 + Generic Rules

Like this:

IdentityNow

IDN Admin Console: v2.4.0

Enhancements

Bug Fixes

Like this:

Uncategorized

Goodbye CSV… Welcome NELM!!!

Like this:

Uncategorized

Guides

IdentityNow Rule Validator 3.0 + Generic Rules

Share this:

Like this:

IdentityNow

IDN Admin Console: v2.4.0

Enhancements

Bug Fixes

Share this:

Like this:

Uncategorized

Goodbye CSV… Welcome NELM!!!

Share this:

Like this: