REST Connector - How to Import Entitlement Without Entitlement Specific API Call

[Kmlynars]

Good Afternoon,

We are attempting to design an integration between Saviynt and a third party tool called Blackline. The API Documentation for this product is available here for reference. This API Includes a Role API Call Which can be used to get all possible roles which can be assigned within the application. However, in order to assign or remove a role from a user, you must use the role-products POST call within the User Management API, which required passing a productID as an argument in addition to the roleID. There is no way to access a list of available productID's within the system via the API. However, you can use the role-products GET call to get an array of the role-product combinations assigned to a user. 

- This means that in order to assign Roles in Blackline, we need to to provide not only the roleID, which we can access via the Roles API call, but also a productID for which the user can use the role with (e.g., "Account", "Journal Document", "Matching", or "Task", with 1 more potentially being added in the near future).

- As previously mentioned, there is no way currently to retrieve products except using the role-products GET call for each accountID, essentially iterating over all accounts in the system to get the role-product combinations assigned to a single user, and eventually all users.

- We've submitted a feature request to the vendor requesting that this information be made available programmatically via the API. It is unclear if/when this will happen, and as such we must proceed using the method detailed above.

Data Structure:

roles GET Call:

user's role-products GET call:

GET user call:

Possible Solutions:

1. Iterate through multipole calls in entitlement import:

- If there was a way to iterate through calls in the entitlement import section, then we can cycle through all account IDs to return all the Role/Product combinations and create entitlements as a hybrid of the Roles and Products for access requests / UARS. For example for the "Preparer" role assigned for the "Task" product, we'd have "Task-Preparer" ("Product-Role"), and then we could parse the Role name during provisioning accordingly.

2. Update Entitlements in Account / Entitlement Mapping Stage:

- If there was a way that we might be able to update the Role entitlement type during the Account / Entitlement mapping. If this was possible, then we could update the Role entitlements with their corresponding Product ID's so we would know which product that they corresponded to for UARs and Access Removal. For access requests, this could be accomplished using a dynamic attribute of type list to provide the 4 (potentially 5 in the future) product options during the Access Request process for selection.

We are open to additional ideas on how to approach this issue as well. If you have any ideas which might achieve this requirement, your assistance would be greatly appreciated.

Thanks,

Kyle Mlynarski

[sk]

Problem I foresee in getting products from user's role-products GET call is that if you don't have any user in particular Product under a role then you will not get that combination or entitlement.

Oneway I can think of is if products are static, Meaning you don't expect see any changes in products or not exponential increase then you can do csv upload those products as entitlements on respective endpoint.

[Kmlynars]

Good Afternoon,

For the sake of this integration, we will assume that each product is assigned to at least 1 user and would be associated with at least 1 role for at minimum the single user assigned that product. This is simply because this is all the visibility into the information that the API provides in its current form. So long as the API lacks direct visibility into the products that exist, then at the very least, iterating over each user would allow us to capture all role-product combinations which are actively assigned. And at the very least would allow for us to remove role-products upon request, during UAR campaigns, and on termination. 

We don't know that the products are static, more products could be added in the future. Also, as we've investigated further, it seems there's no way to perform data manipulation within the "acctEntParams" section, meaning even if we were able to use a CSV import to create entitlements that are a concatenated version of the Role ID and Product ID (e.g., "A-1234" for Product A, Role 1234 or "B-2345" for Product B, Role 2345 etc.), there would still not be a way to get an "entIdPath" from the API response that would provide this concatenated value. As such, there'd be no way to tie the role/product association back to the account from the "roles-products" API response, as there's not a single field that would hold this concatenated value in the API response (and as mentioned, we can't do data manipulation to create this value for mapping to an entID from the API response). As a result, we don't see a pathway for tying role/product associations (multiple IDs) to a single entitlement ID.

Thanks,

Kyle Mlynarski

[SB]

This is currently not supported but you could raise an enhancement request for the same on ideas portal.

https://ideas.saviynt.com

[rushikeshvartak]

Can you share your working JSON's

[rushikeshvartak]

https://ideas.saviynt.com/ideas/EIC-I-4143