Web Service Entitlement Management Question

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

Hi everyone!

I hope you’re all having a great week! I recently ran into an issue with a third-party app where the vendor made some unfortunate design decisions in their new API spec. I will try to lay out the issue as best I can below.

Originally, I was aggregating users as accounts, and groups as entitlements. Users are associated with groups in the user aggregation where the groupIDs they are a member of are returned as an array of integers on their user record. This worked completely fine, I just set the integer groupId as the native identity of the groups schema and everything was associating in ISC as it should.

Recently, they changed their API spec to use a new GUID attribute instead of the integer ID as the unique ID for both users and groups. I figured I should be able to just swap the native identity on both users and groups to this new attribute and be done with it.

Unfortunately, while the user and group aggregations are pulling the new GUID correctly, the array of groupIDs a user is a member of is still using the old integer ID instead of the new GUID. So, if I change the native ID of the groups, the entitlements no longer correlate with the user accounts in ISC. If I don’t change the ID, the entitlements correlate, but the add/remove entitlement operations no longer work because they’re passing the wrong ID from my $plan.securityGroups$ keyword in the add/remove operations.

My only idea at this point is to write a post-aggregation rule and translate the int groupID to the GUID so I can make the GUID on the group schema the native identity. That’s not particularly difficult but it’s also something I’d have to maintain until the vendor fixes their API so the unique IDs are the same thing in all their endpoints.

I’ve been looking through various posts and documentation trying to figure out if I can pass the group guid to the add/remove operations via a keyword without it being the native ID of the group objects. Does anyone know if that’s possible, and if so, how I would go about properly referencing the attribute in a keyword?

Any other ideas or thoughts would also be welcome! Thank you for taking the time to read this post and any ideas you might have.

2

Hello @zbetz

Please recheck your response mappings , as you mentioned the API response is changed . Make sure you are mapping the ent attributes to the right response attribute

Have you performed Entitlement Reset and Accounts Reset on the Source ?
If not please perform these and try .

  • First Remove all accounts:
    {{baseUrl}}/sources/:id/remove-accounts
    Then remove all entitlements:
    {{baseUrl}}/entitlements/reset/sources/:id
  • Check your schemas , account and entitlement .
  • Aggregate Accounts
  • Aggregate Entitlements

Thank you

3

Hello @sidarth_tarlapally!

I haven’t done a full reset yet, however I’m not sure that it’s necessary. I can get the entitlements to correlate just fine, however when I do, the ID of the entitlement in Sailpoint is an attribute that I can’t pass to the add/remove entitlement APIs in the third-party application.

The objects in question look like:

User Object

{
	"id": 1234
	"guid": "cf50cc94-f6d6-4c11-8819-bb69a69934bd"
	"firstName": "firstName"
	"lastName": "lastName"
	"securityGroups": [
		1,
		3,
		5
	]
}

Group Object

{
	"id": 1
	"guid": "cd671392-bb4f-47eb-9a33-bb5860f8f2a9"
	"groupName": "Some group"
}

So, by making the “id” from the group the id in the ISC entitlement schema, the user entitlements correlate correctly, however the API wants the “guid” attribute from the entitlement when sending an add/remove entitlement request.

That’s what I’m struggling with at the moment.

Hopefully that makes a bit more sense?

4

Get It !

Correct me if my understanding is wrong :
The user account will have a reference to entitlement id which cannot be used in making api calls

In this case you have to modify the ent attribute value in the after aggregation rule , which has to bring guid instead of id.
Or
Before operation rule on both revoke and add operation, where you have to modify the end point url , fetch guid using the nativeIdentity in the plan [id]

5

That’s correct.

Ok, that’s kinda what I figured I’d need to do. I had been hoping I could reference the guid attribute with something like $plan.securityGroups.guid$ but I guess that’s not possible.

I was able to write an after operation rule for the account get to translate the [id] of the security groups to the [guid]. I’m currently working on making an after operation rule for the full aggregation as well.

Thank you for the input, I greatly appreciate it!

1 Like
6

Yes Zach !You are right We cannot refer other attributes apart from the Ent ID .
Thank you !