Birthright Provisioning in SailPoint - How to start?

Provisioning through SailPoint, I wanted to do this from quite some time. Certifications are one major requirement for customers but now lot of requests are coming in for provisioning through SailPoint, and customers are comparing Tivoli, Oracle and SailPoint suites to find the best possible provisioning solution.

In this blog I am going to write about a simple birthright provisioning solution that can be created to understand how it can be done using the workflows. 
Birthright provisioning is the scenario when every user who is present must have access to a specific application. (Could be ad/exchange or intranet site)
There are other ways also(like roles or provisioning policy etc..) which i will be explaining in future posts.

In brief what I have configured is a open DS ldap server as a application in SailPoint. and then create a new account for a user through LCM as soon as the identity is aggregate in SailPoint(BirthRight!!), and the request will be processed using a workflow which will send a custom form to the manager for approval.
LDAP connector in SailPoint supports direct provisioning hence no connector gateway configuration is required. 

 How to do that :- (Pre-requisite enable LCM and account request)

1. Once you have configured LDAP application in SailPoint, make sure it has "PROVISIONING" added in feature string.

2. Workflow attributes :- Workflow attributes are basically which will hold the required objects and values which will be passed along the different steps of workflow. (For example you wan to pass values from a form filled by manager to next step, where you want to create account  based on the attribute).

It is difficult to initially identity what all variables will be required for provisioning, you can identify the variable required once you select the existing function from the "call method" and hover the mouse over it. It is better to refer existing LCM provisioning workflow and copy the major required variables.

3. Workflow flow :- For creating the workflow in UI, drag and drop the start, setp and end steps from the UI. Make four steps (Approval, Plan, Compile plan, and execute plan).

5. Approval/Form :- In the first setp add a approval and a from, in the form add fields you want to present to user for input, these fields will be available for use in the next step. Add a condition when the form is approved then only go to next step else end. This step can be leveraged to get the necessary input from the manager to create the birthright account.

6. Plan :- In this step you need to create a plan using the ProvisioningPlan class, the identity for which the account is requested will be available as input(identityName), which can be leveraged to create plan object which will be a return variable from this step.

7. Compile and Execute steps:- In next two steps call existing functions from the workflow library compileProvisioningProject and provisionProject. Required variables needs to be added to the argument tab.

8. Trigger :- Update the existing worfklow in Lifecycle events with your new workflow. In the refresh identity cube task "Process Events" needs to be selected which will trigger the workflow for any new identity aggregated.

If everything is configured correctly then a account should be created in OpenDS. 

P.S:- I have not added lot of technical details in this post, but I am sure with the points above somebody who is trying to start with workflows can understand and do it easily.

Flat Files for application on-boarding

Flat files or mostly known as csv files is the most common format in which applications prefer to give the data. In most of the projects, I have seen people writing a separate utility(java) which will actually validate the flat files, and convert it into a desired format before sending it for import, or store it in a custom database and read using jdbc connectors.
This design actually expedites the process of on-boarding if all teams are agreed upon a fixed format, though for the long term Identity and access management road map this files needs to be replaced with direct connectors to achieve auto provisioning and de-provisioning.
In SailPoint we have some options build in the tool to read and modify the file using rules like(build map, pre-iterate, post-iterate, File parser rule). This rules gives the flexibility of writing custom logic per application, but it requires more effort in maintenance and future enchantments.
So either having a fixed format of file or different format of file for every application, both have advantages and disadvantages, and none of the option can be picked without looking into all aspects of the enviornment.

Scopes in SailPoint IIQ

There is very common requirement in any IDM project that a manager should be able to see the users only who are his direct reports, could be very easily achievable in some tools like in Sun IDM or Tivoli IDM. But in some tools it is really hard to configure like CA IDM, or Aveksa.
In this post I will talk about configuring this feature in SailPoint. 
I will try to explain a simple configuration using an example of department. Let's say there are two departments Banking, and Media, and a banking manager should only see his people in Banking department. 

• Go to System Setup -> Scopes
• Enable scoping
• Select the attribute in Scope identity attribute, which contains the value of department
• Scope correlation is required if you do not have a specific scope attribute like department, or multiple attribute contains scope values.(not required for this example)
• Scope selection rule is required in case scope has to be decided in case of multiple scopes returned from the above rule. (not required for this example)
• Unscoped Objects Globally Accessible, as the name suggests if you want the unassigned scope objects to be accessible.(for example who doesn't have department attribute and no scope is assgined to it).(not required for this example)
• Identity Controls Assigned Scope , this is also not required for this example. This basically allows all users within the scope to manage users within the same scope, but this will only happen with the combination of correct user capabilities.(not required for this example).
• Run the refresh task to create the required scopes.
• The task will create scopes of all departments, and you can view them in scopes option in System Setup.
•  Not go to identities and identify a user in Banking department, who will be managing all the users in Banking.
• Go to User Rights tab and in Authorized scopes, select Banking, and assign appropriate user capabilities.
• Now login with the user you just modified, you will be able to see only those users are under the same scope.
• A lot complex scope can be created using multiple attributes for scoping and using the custom scoping rule.

Done!! :)

Managed Entitlement Customization Rule SailPoint IIQ

Managed entitlement customization rule is quite useful in SailPoint if there are huge number of entitlements, for example some AD groups and descriptions can be set based on the name of the groups.

However, there is a big disadvantage in using this rule, the description will be updated only first time when the entitlements were found and brought into managed entitlements. 

The "Promote managed entitlements" task or "Missing managed entitlement scan" both tasks can be used to find the missing entitlements, and execute the rule to update the descriptions of the entitlements.

But if the rule is not specified in the rules tab of application definitions, and either of the tasks("Promote managed entitlements","Missing managed entitlement scan") is executed, then the entitlements will be updated without any descriptions, and running the rule next time won't update the existing blank descriptions.

Also if there are more than one entitlements attributes with same entitlement value then by default the rule will only updated the entitlement which is passed to it first, to avoid this scenario both entitlement attribute and entitlement value needs to be checked before updating.

Sample rule

String filter = "Update"

//To get the entitlement value
String ent = attribute.getValue();

//To get the name of attribute if there are more than one attribute with same entitlement values
String attr = attribute.getAttribute();


if(ent.contains(filter) && attr.equals("groupA"))
{

attribute.setExplanation("defualt","This is description of groupA ..... ");
}

Extending/Creating CA e-trust directory schema

For CA Identity Manager user e-trust directory is must to use ldap. In the post I am writing few basic things which are require to know in CA-etrust Directory

1. Creating new schema -

After you install the etrust directory open the command prompt and run the following command

dxnewdsa <> <> "<>"

example

dxnewdsa corpstore 11389 "dc=com"

where "dc=com" is root dn
corpstore is directory name and 11389 is the port number

2. Extending the e-trust scehma

for extending the etrust schema create a new file with extenstion .dxc. The contents of file will be in following format

schema set attribute (1.1) = {

name = employeeID

ldap-names = employeeID

syntax = caseIgnoreString

single-valued

};

schema set object-class (1.1) ={

name = CAPerson

ldap-names = CAPerson

subclass-of inetOrgPerson

must-contain objectclass

may-contain

employeeID

};



The syntax is very simple in the first section you have to write all the attributes with schema set attribute(1.2) and then the properties of the attribute and in the second section write the name of the new class and the attribute comma separated after "may contain"
After the file is created add the new schema file in default.dxg file in schema folder