Mapping Entitlement Additional Attribute to Entitlement Description

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hi,

We recently got to the point of being able to see an important “Additional Attribute” in our Workday Accounts entitlements by the name of COMMENT. This property correlates to what we’d like to see as the overall entitlement description, however that is not the way the connector behaves out of the box.

I’ve attempted to look at the source schema via API (and compared it against the ServiceNow connector, which does support automatically associating a “description” Additional Attribute as the overall entitlement description), however I’m not able to glean what exactly I’d need to do to hopefully set that COMMENT property as the entitlement description.

Without this, I envision us needing to script something along the lines of:

  1. REST call to GET all entitlements for Workday Accounts source
  2. Formulate request body for PATCH entitlement for each entitlement that will need to set a new description as the value of the COMMENT field from step 1 entitlement blobs.
  3. Call PATCH entitlement endpoint X times for each entitlement that needs the updated description.

This wouldn’t be the end of the world for us, but if we could circumvent that with a simple config change in in the UI or API, that would be much preferred.

I’ve included a screenshot of Workday Accounts entitlement view (which we’d like to see behave differently), a screenshot of a ServiceNow entitlement as comparison to what we’d like to see, along with shortened versions of the json source schema blobs for each of the sources.

My observations thus far are:
a) the ServiceNow connector is able to automatically map Additional Attribute description fields to entitlement descriptions, potentially because they are already named “description.” If someone could confirm if this is under-the-hood magic, that’d be helpful.

b) I also notice that the nativeObjectType is different between the sources – Workday Accounts has nativeObjectType “SecurityGroup”, while ServiceNow has nativeObjectTypes “group” and “role”. I wonder if this might lead to hidden behavioral differences.

workdayAccountsSchemaAbridged.json (2.7 KB)
SNOWSchemaAbridged.json (5.1 KB)

WorkdayAccountsEntitlementView
WorkdayAccountsEntitlementView3256×1046 195 KB

ServiceNowEntitlementView
ServiceNowEntitlementView3498×1586 306 KB

Thanks!

2

Hi @imckenzie, if some connector has a specific description field; then that maps with the IdentityNow description column. That varies and should not be compared with each other. Can you try this one for updating the description attribute and then performing aggregation -

Update for this end-point: /sources/{sourceId}/schemas/{schemaId}
Method: PATCH
Headers:
Content-Type: application/json-patch+json
Payload:

[
{
"op": "add",
"path": "/configuration/descriptionAttribute",
"value": "COMMENT"
}

Thanks!

1 Like
3

Thanks Dinesh, that works as I’d hope, appreciate the help!

4

Hi Dinesh, one semi-pertinent question:

Do you know if there’s any support via the Workday Accounts connector for implementer or segment-based security groups? If not, is that something that would potentially be on the team’s radar to support in the future?

5

Also, could you point me towards any additional documentation on this “configuration” object within a source’s schema?

6

Hi @imckenzie, I am not sure whether it will be feasible or not considering the API availability; however, we do have a plan to check on it further in near future. If there is some pointers or you had any communication earlier with Workday, feel free to share the information with us. Thanks.

7

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.