We require guidance on implementing a secondary account creation scenario in SailPoint Identity Security Cloud.
Current Configuration:
We have ApplicationX integrated via a direct connector (SourceX) with the following entitlements defined:
Viewer (non-privileged entitlement)
Reader (non-privileged entitlement)
Admin (privileged entitlement)
AdminDB (privileged entitlement)
Business Requirement:
We need to implement automatic account type differentiation based on the privilege level of the requested entitlement:
Non-Privileged Entitlements (Viewer, Reader):
Create a standard user account on SourceX
UserID format: j.smith
Privileged Entitlements (Admin, AdminDB):
Create an administrative account on the same SourceX
UserID format: j.smith.admin
Scope:
This requirement should be applicable to various application types, including but not limited to:
Active Directory
SAP
Custom applications
Web Services
ServiceNow
Other connector-supported applications
Question:
What is the recommended approach to implement this secondary account creation logic in SailPoint ISC? Are there specific configurations, transforms, or provisioning policies we should leverage to achieve this behavior?
Since it is not possible to retrieve an identity’s entitlements via transforms, I think that a rule is necessary for this usecase;
You can use a beforeProvisioningPolicy and detect if the operation is Create account, then you can then retrieve the entitlement of the identity being processed, if an entitlements from ApplicationX contains “Admin” in its name (or flagged as Privileged), then you can add “.admin” to the UserID and and set the value.
This will replace the userID that was put by the account creation profile (j.smith) by setting (j.smith.admin)
This rule could be used generally for all ApplicationX since you can use the value of the source concerned using application.getName(), etc.
You can use this method to set the value UserID inside your code :
public AttributeRequest setAttributeRequest(String attributeName, Object attributeValue) {
AttributeRequest attributeRequest = new ProvisioningPlan.AttributeRequest();
attributeRequest.setOperation(ProvisioningPlan.Operation.Set);
attributeRequest.setName(attributeName);
attributeRequest.setValue(attributeValue);
log.error("Email calculation New Rule - attributeName : " + attributeName);
log.error("Email calculation New Rule - attributeValue : " + attributeValue);
return attributeRequest;
}
Of course you will have to process the accountRequests of the applicationX until the Create operation is there, then you look for entitlements, and do you check, if Admin, apply the change in userID :
for (AccountRequest accountRequest : plan.getAccountRequests()) {
if (accountRequest.getOp().equals(ProvisioningPlan.ObjectOperation.Create))
You can find your way on how to inspect entitlements but i believe their included in the accountRequest as well, but you need to check that)
How can I detect the Create Account operation if this operation is triggered only the first time that an entitlement is added ?
This is an example:
We have the unique source called AD_TEST (is an Active Directory Source).
We have 4 groups:
Viewer (non-privileged entitlement)
Reader (non-privileged entitlement)
Admin (privileged entitlement)
AdminDB (privileged entitlement)
The user j.smith use the request center in Sailpoint and manually request the group “Viewer“. This is the first entitlement, so the connector will trigger the Create Account operation + add entitlement. The account AD created has samAccountName=j.smith (provisioning policy standard)
The day after, j.smith use the request center again and requests the group AdminDB (privileged entitlement). This is the second entitlement, so (I think) the connector does not trigger the Create Account operation but directly the add entitlement operation. And by default it will use the account AD j.smith
I don’t want this behavior. I want that when the user will request the group AdminDB (privileged entitlement), Sailpoint will generate a new AD Account with samAccountName=j.smith.admin and will add the entitlement AdminDB to this new account.
I was told its not a good idea using the same source put rule to create 2 account. I one approved way is to have 2 sources for same target. say,1) AD and 2) AD Privileged.
you can try to change the operation from modify to create using eventActions but still consider build logic to identitfy if the identity already secondary account, the logic to build new attrs etc…list will keep going on your needs but again having a an other source is one way. but if sure already has 2 accounts, consider access policies.
I thought you want to create either Standard or Admin account, but not the two at the same time.
Well, in the case you described, the best practice is to create two connectors, each one with reads the access related to it (Admin OR Standard).
Having two accounts for the same identity in one connector will create issues in for transforms of type accountAttribute as ISC won’t know which account to take into consideration. The same issue is applied for access provisioning since ISC won’t know to which account it should provision the access (there is a solutionfor this one with the “Multiple account Option” in Access Profiles, but it will be an enormous load of work, and won’t resolve the Transforms problem).
I don’t think that’s exactly accurate. Adding more sources in this context refers to downstream application connectors, not HR or authoritative identity sources. Since identities are created by HR systems (or other authoritative sources), duplicating application sources will not create additional identities. The accounts from both the standard and admin sources will correlate back to the same identity record, so there’s no impact on licensing at all due to this approach.
Correct, for each application where you need separate handling of privileged accounts, you would configure a duplicate source. As a best practice, configure account filters so that:
The primary source excludes admin accounts during aggregation.
The admin source only aggregates admin accounts.
This keeps the two account types isolated, while still correlating them back to the same identity. It also ensures provisioning policies can be tailored separately for standard and privileged accounts.
Lite Identity [-LU] - A Person or Machine whose access within the governed environment is limited to five (5) Sources.
One can request lite identities in their licensing agreement as a cost saving strategy. They typically cost about 20% less than a full identity license, but that is a negotiated rate.
So introducing additional source accounts may result in identities being connected to more than 5 sources, which would affect their licensing agreement if lite identities are included in it
I think you’re right about the licensing definition. That said, in practice I believe it’s hard to imagine most users staying within the 5 source limit required for a lite identity classification
Take a typical onboarding flow as an example:
The HR system creates the identity, which immediately results in two accounts : one in the HR source and one in the IdentityNow source
Next, almost every user will need an Active Directory account
For collaboration & productivity, they’ll also get an Azure AD/O365 account.
In many organizations, a ServiceNow or similar ITSM/ticketing system account is provisioned as well
At this point, the user already has 5 source accounts correlated to its identity, and that’s before considering any business applications. In reality, most users will have additional downstream accounts, which means they wouldn’t qualify for lite identity licensing anyway
So while the licensing definition according to SailPoint is technically correct, the operational reality is that the majority of users will exceed the lite identity threshold very quickly