Thank you for involving us @colin_mckibben! Resetting entitlements and resetting accounts indeed has priority, but there is indeed more to consider when talking about resetting a source.
Reset entitlements:
With reset entitlements I understand āremove the entitlement from the knowledge space of IdentityNow, ignoring audit logsā. An entitlement aggregation might result in bringing these entitlements back, where they might obtain a new id (the big number generated by IdentityNow).
Will it be possible to reset particular entitlement types? For example ServiceNow has entitlements of type āgroupā and entitlements of type āroleā, can we reset only the entitlements of a particular type while keeping the other entitlements?
Please ensure that it is clear in the documentation what will happen when access profiles are already defined for this source. Will they end up as empty access profiles, that keep the information like owner, approval flow, role and segmentation mapping? Will they be removed automatically if it would not contain any entitlements anymore?
Reset accounts
Resetting accounts in my opinion would be similar to applying the API DELETE /cc/api/account/remove/id, but then in bulk, so that we donāt have to perform this API 100k+ times. Right now the current reset accounts API refuses the request when the source happens to have accounts belonging to an identity who happens to be the source owner for other sources, even when the account you want to remove is not the authoritative account. It would be great if this new API would not have this design flaw.
Reset (manual) correlation
As far as I see, once an account is correlated to an identity, it stays correlated to that identity, even when the correlation criteria changes or when the account attributes changed significantly. I believe this is a nice desired effect, but it can happen (both when onboarding a source and making many configuration changes) or in production, that we need to keep the accounts, but reset the current correlation between account and identity, to ensure that the accounts might switch identity. This could happen in 3 different scopes:
1: Retry correlation of all uncorrelated accounts
2: Retry correlation of all uncorrelated and manually correlated accounts
3: Retry correlation of all accounts.
One could say ājust reset the accounts and aggregate the accounts againā and while this will achieve the desired effect, this operation might be too drastic and have undesired consequences. For example accounts that were already correlated correctly would (when using the reset accounts option) be removed from the identity before getting placed back to the identity, which can have a bad effect on dependencies such as transforms referring to the account attribute, birthright roles with membership criteria dependent on account attributes/entitlements and workflows getting triggered again. Also the account ids would reset if we remove the accounts.
Reset session related attributes
The integration might rely on obtaining an access token from the application using client id&secret or name+password. That access token is now used by the source (I believe it can be found encrypted in the json connectorAttributes), until it expires and requires another access token. One would expect that resetting a source means that this access token is removed as well, and that the integration needs to request a new access token using the saved credentials. Also other session related such as cookies should be reset.
Reset Delta Aggregation information
If we perform delta aggregation, the source might ārememberā when the aggregation was successful for the last time, to ensure it can ask the application for all changes (Creates, Updates and Deletions) since a specific moment. Resetting a source would also mean we need to forget about this timestamp.
Reset custom selected attributes
Since IdentityNow offers custom rules where we can read and write data to the source (using key value pairs in the source json connectorAttributes), it could be that resetting a source means resetting some of those attributes values, either by resetting it to a default value, setting the value as null, or by simply removing the key value pair. Of course we could remove those ourselves, but since the connectorAttributes consists of many key value pairs, some added by IdentityNow (dependent on the connector), some added by us, it can be chaotic quickly in that json file (especially if we want to export the source and import it to a different IdentityNow environment or duplicate the source). Sometimes we would want to specify which custom attributes should be part of a reset.
Source internal name
Suppose we are not paying attention when we create a source in production for AD and we call it Active Distractory, we load the accounts, entitlements, setup everything and realize the typo in the source name, so we fix it by renaming the source. We are not going to remove the source again anymore since many dependencies are already active and the source name is corrected right? But if we now check the json, we will find the element accountCorrelationConfig still referring to the error:
"accountCorrelationConfig": {
"type": "ACCOUNT_CORRELATION_CONFIG",
"id": "2c9104857befdff9067c017aab3b00d5",
"name": "Active Distractory [source] Account Correlation"
}
Changing the account correlation will not have an effect on this name. Also, several current and future audit logs refer to the source by this typo. It would be great if we can reset this āinternally used nameā
Select elements to reset
Right now the API offers ways to skip elements of the reset. Like ?skip=accounts.
I am not sure if it would be better to have an API where we can say āreset the source, except for accounts and correlation and delta aggregation informationā or if it would be better to have an API where we can say āreset the source, but only regarding entitlements and session related attributesā. AKA provide an inclusion list or an exclusion list. I guess it is most important as long as it is documented properly.
Desires v.s. expectations
I understand I am asking more than what is already being offered on the cc/api API and that it is not realistic to expect all of this to exist on the new API before the old one gets deprecated, but I nevertheless want to point out to the engineering team that this would be very useful for us to have. Perhaps the new APIs could be designed whilst keeping these future functionalities in the back of the mind.
