Provisioning rules

For each application in the above list, complete the matrix below Along with the application name, it is important to know how the value should be generated. The example below uses a subset of attributes found in Active Directory .

Application Name: Active Directory

Field NameDescriptionRules to generate value
sAMAccountNameUser identityLimited to 20 characters. First 19 Characters of Last name + first letter of first name. If its not unique, then 18 characters of last + first character of first name + numeric value which is incremented by 1. Example: smithw, smithw2, etc.
userPrincipalName
cn
dn
givenName
middleName
sn
ExtensionAttribute10
title
EmailAddressEmail addressFirstname + "." + lastname + "@mycompany.com". If the email already exists, then Firstname + "." + lastname + "2" + "@mycompany.com"
memberOf
mobile
path (ou)OU in which the user will be createdOU is linked to Department. Maintain an Department to OU mapping which can be used to determine the OU

Example 1: Application Name: My Business App

Job TitleOrganization / Division / DepartmentAccess
Accounts Payable ClerkFinanceGrant membership to Role: View - Invoice
Senior ManagerFinanceGrant membership to Role(s): View - Invoice, View - Approvals

Example 2: Application Name: Active Directory

Job TitleOrganization / Division / DepartmentAccess
Accounts Payable ClerkFinanceGrant membership to group: CN=Finance,OU=Groups,DC=openiam,DC=net

If users will be able to request access to the above applications from the self-service portal, then define an approval-flow for each application

Approval flows can be defined at either the application or entitlement level. Often, it is most practical to define the approval flow at the application level and then override that flow at the entitlement level. An example of an approval flow is:

  • First approver: Manager
  • Second approver: Application Owner