SailPoint IdentityNow - Orphan accounts management

IdentityNow integration series

After a taking a long break, let me introduce you to one of our newest platform additions through a very common use case. I'm talking about SaaS Connectivity in order to extend out-of-the-box platform capabilities to manage orphan accounts.

SaaS Connectivity is our (fairly) new custom connector framework that allows to create custom connectors that do not require a virtual appliance to run. Some may find these new framework specially appealing because of it running from the cloud, others because of its ease of development for any SaaS application. At the end of the day, both are very good reasons to consider this new framework as a replacement for web services connectors or a new means to easily integrate cloud systems for which there is no dedicated connector. I encourage you to check out our documentation and get acquainted with it. It's extremely helpful.

This time I bring you a custom connector that enables IdentityNow to extend the default orphan account management capabilities by leveraging this framework and IdentityNow API. In particular, this connector allows to:

• Manually correlate orphan accounts to identities by access request
• Disable original orphan accounts by disabling virtual identity/account from the connector
• Disable original orphan accounts by certifying access from virtual identities from the connector

Our current orphan accounts certifications only allow to certify access but not the account itself. This, in my opinion, only covers one of the typical use cases around orphan accounts. One may find useful to certify orphan accounts that are in fact known service accounts or similar entities. However, when an orphan accounts is found we generally know little about it. We don’t know whether it’s a legit account. It may be a correlation failure, a test account, a service account, an old employee account, a backdoor account, etc. We probably best start by disabling it, doing some research and based on the results delete or correlate to an identity. We can then start certifying access now the right context is in place.

In combination with existing functionality, this connector provides a good foundation for orphan account governance by adding manual correlation and account disabling to the existing access certification capabilities. It also makes reporting easier.

Supported use cases

Manual correlation

The connector creates a series of account and entitlement pairs for those uncorrelated accounts found in the specified target sources:

You can use those entitlements from the request center to request the account to correlate on behalf of the identity you want to correlate to:

Manual disabling

You can create a new identity profile based on the orphan accounts source:

Once in place, you can manually disable the resulting account from the identity in order to disable the original orphan account:

Disabling by certification

With an identity profile in place, you can certify the whole source or a subset of identities:

By revoking the only entitlement those identities have you’d be disabling the original orphan account:

Disabling by lifecycle management

With an identity profile in place, using the same manual disabling mechanism, you can automatically set a LCS that disables all or a subset of the identities from the connector:

Pre requisites

SaaS Connectivity enabled on IdentityNow tenant and a Pipedream account.

Limitations

Manually correlated accounts still appear as orphan accounts until the next aggregation. This can easily automated with Pipedream or other means, hopefully soon with our internal workflows too. It shouldn’t be too much of an issue but it depends on the context. Risks are the account was correlated but it’s also the target of a certification or a manual action and you end up with a disabled correlated account.

Configuration

1. First of all, you need SaaS Connectivity enabled on your tenant. Open a switchboard ticket and request it.
2. Deploy the connector using this source code.
3. Configure an identity profile based on the new source if you need disabling accounts capabilities.
4. Deploy this workflow on your Pipedream account. This is an optional step that helps making all resulting entitlements requestable if you need to publish many, since we have a bulk operation limit of 50 that also affects the UI.
5. Configure the following variables using your tenant information and personal access token:

That's all. I hope you found it helpful. Stay tuned for more.