Best practice to create account certification for connected source in Identity Now/ Identity Security Cloud. Need to consider both correlated and uncorrelated accounts from the source.
In Identity Now/Identity Security Cloud we don’t see account certification using OOTB features. Can anyone suggest how are they doing account level certifications for the connected source in your INOW/ISC tenants.
Certifications in SailPoint ISC are typically performed at the identity level, which applies to correlated downstream application accounts. You can leverage either built-in certification campaigns like Manager or Source owner (or) you can use the search-based certifications to review entitlements and account access for these users.
For uncorrelated accounts, SailPoint provides an out-of-the-box Uncorrelated Account Certification option that can be initiated directly from the search interface. This allows you to identify and certify accounts that aren’t linked to any identity, helping maintain governance across all account types.
I have tried uncorrelated account certification in the Identity Now but we can only review the access items(Entitlements,AccessProfiles) but we can’t certify the account directly. In other available certifications also we can only review the access items but not accounts. In Sailpoint IIQ we can review the accounts,when reviewer revokes we would either disable/delete the account based on the application specific requirement. I wanted to do account level certification in Identity Now but don’t see any OOTB certifications related to accounts review.
You’re right about how this works in IIQ, @EdulabaviAkhilTeja. However, unlike SailPoint IIQ, ISC doesn’t currently support true account level certification out of the box. The certification framework in ISC is primarily designed around access items such as entitlements, access profiles and roles that are linked to identities.
While ISC does offer uncorrelated account certification, it’s limited to reviewing associated access and doesn’t allow direct certification or remediation of the account itself. This is due to architecture of ISC, where provisioning and deprovisioning actions are entirely access-driven, which explains the current behavior. Hope this answers your question.
Do we have any other possible way to do Account level certification using any different approaches. Did you get a chance to do account level certification for any of the clients using any custom solutions in the Identity Security Cloud. If you have done it, please share the approach you followed.
With ISC, unfortunately this isn’t feasible. You can check the product documentation here - Starting a Campaign from Search - SailPoint Identity Services
You can only certify :
Not really, you might want to explore a custom built solution outside of SailPoint ISC for this.
Yes.
Account only certification is not available OOTB.
One work around that we may try is the following.
Create a webservices source which calls the internal ISC search API.
Every identity shall become an account in this source.
Entitlements shall indicate be the different sources. If an identity has an account in this source “A”, this shall lead to entitlement called “A” for the account representing this identity. Different accounts available is already available in the search API response.
Run an “Access Item” certification focusing on these source entitlements.
What you get is similar to an account only certification.
To expand on Arshad’s thoughts, in one of my implementations the ask was to perform account certification on a delimited application, my recommendation was to implement the following process for entitlement creation:
Identify Key Attributes: First, determine the essential attributes that define a user’s account (e.g., Role, Department, Region).
Concatenate Values: Combine these attributes into a single, unique value in a new column.
Promote as Entitlement: This newly generated composite value should then be formally designated as the user’s entitlement within the system.
It’s important to note that this approach won’t work for applications using direct connectors. While we could use a loopback connector as a workaround, it would introduce extra data that would confuse certifiers. For me, keeping the end-user experience hassle-free and self-explanatory is the priority.
Regards,
Aman
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.