Webservice Connector - Remove account when there is one entitlement left

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

I am able to remove entitlement on Remove Entitlement operation when manager revokes the item. But there is a use case when manager revokes the entitlement and there is only one entitlement present with user then the respective account should get deleted.

Can anyone please let me know how this can be achieved?

2

Hi Amrit,

You could develop a Before Operation rule, and check whether this is the only entitlement left, and if so, change the operation to Delete etc

3

Hi @Amrit1897,

You can achieve this usecase through Web Service before operation rule. Find below link and develop a Web Service Before Operation rule.
Web Services Before Operation Rule (sailpoint.com)

Thank You.

4

Hi @gogubapu, I don’t it would be possible. Correct me if I am wrong.
In the before operation rule, from plan we can get native identity and entitlement. But I don’t think it would be possible to call identity and managed attribute object to check if user has entitlement already.

5

Hi @Amrit1897,

You can use below API to get the account details from before operation rule and then accordingly modify the plan as per your use-case.

Let me know if there is any specific issue.

Thanks

1 Like
6

Develop rule using below suggestion:
build logic:
In web service after operation rule get single user data, then check user entitlement, build condition if user have this particular entitlement, then execute delete user API in the same if condition.
4. then patch the web service after-operation rule to remove entitlement http operation and find below link after operation rule
Web Services After Operation Rule (sailpoint.com)

Thank You.

7

Hi @Amrit1897

Is there a particular reason you would want to delete the account when user has 1 entitlement remaining because this sounds strange to me that user will have the entitlement in the back-end application and we try to delete the account.

Generally, the account should be deleted when last Entitlement is being removed from the account and for this there is already before provisioning rule available (Services Standard IdentityNow BeforeProvisioning Rule) which lets you achieve this use by just configuring the events on the source level.

So, the idea is you can configure the below trigger on the source and then this will detect when ever the last entitlement is being removed from the user, the modify operation will be changed to delete operation and it will ensure that account is deleted from the back-end.

 "eventActions": [
                            {
                                "Action": "ChangeOperation",
                                "Attribute": null,
                                "Value": "Delete"
                            }
                        ],
                        "Operation": "Modify",


"Entitlement Cardinality Update Triggers":[
 {
 "Attribute":"groups",
 "Operation":"LastRemoved",
 "Value": null
 }
]

FYI, you will need to change the attribute value in above example and keep the attribute name for entitlement. Also, you will need to contact SailPoint to deploy this rule in your tenant.

Also, make sure that delete operation is defined on the connector configuration.

I hope this helps.

Regards
Vikas.

1 Like
8

@vguleria Good to see how you configured this… I have one question, I do not see “eventActions” as connector attribute are we allowed to add it under connector attribute? are you saying update the source using the API?

@Amrit1897
I have another approach to achieve this usecase:

  1. Write a beforeProvisioning rule - where you will check if the entitlement which is getting removed is the only entitlement and change the operation to delete.
  2. Have HTTP operation “Delete Account” configured in your source.

Regards,
Shekhar Das

9

Hi @shekhardas1825

Yes, typically you would create a new key inside the connector attributes called as cloudServicesIDNSetup and there you can create multiple events as per your use case. The standard rule is also quite flexible as you can have multiple events for example if you want to move user from one OU to another one.

  {
	"cloudServicesIDNSetup": {
		"eventConfigurations": [
			{
				"eventActions": [
					{
						"Action": "ChangeOperation",
						"Attribute": null,
						"Value": "Delete"
					}
				],
				"Operation": "Modify",
				"Entitlement Cardinality Update Triggers": [
					{
						"Attribute": "groups",  // this will change and instead of groups, it should be your entitlement attribute name
						"Operation": "LastRemoved",
						"Value": null
					}
				]
			}
		]
	}
}

It is quite easy to configure this. The only thing is that you will need to contact SailPoint to deploy this rule to your tenant. Once deployed, you can use it for multiple sources and multiple events can also be configured there.

You can even do something like when last entitlement is removed, then change the operation to disable if you do not wish to delete the accounts, so in my opinion this will be better option to go for. But please make sure to check with SailPoint support if you can get it deployed on your tenant or does it require some more pre-requisites.

I hope the information helps.

Regards
Vikas.

1 Like
10

Thanks @vguleria for explaining, this is really good.

11

Hi @ashutosh08, Thanks for the suggestion.
So, if I use the api inside the rule then I have to store clientid and secret inside the rule itself?

12

@shekhardas1825, Thanks for the suggestion.
In the before operation rule, from plan we can get native identity and entitlement. But how can I get the identity information, like user has only one entitlement left?

13

@gogubapu, Thanks for the suggestion.
Can you please tell how before provisioning rule would look like or you mean to say before operation rule?

14

Hi @Amrit1897

This is a standard before provisioning rule with the name “Services Standard IdentityNow BeforeProvisioning” Rule. You will need to get it deployed by SailPoint support team once in your dev tenant.

Once it is deployed, then you can map the before provisioning rule in the source and then configure the events to change the operation to delete when the last entitlement is being removed and perform the testing. If the tests looks promising, then you can use sp-config APIs to move the rule from dev to production tenant.

So in short, it will be only one time request to SailPoint for deploying the before provisioning rule and after that it will let you achieve many use cases with it without having to manage your own code.

I hope this helps.

Regards
Vikas.

2 Likes
15

@vguleria, Thanks for the suggestion.
Do we have any documents available which tells what this rule does?

16

Hi @Amrit1897

Unfortunately i am not aware of any standard documentation if it is there. But you can download the zip file from the mock project link below.

https://community.sailpoint.com/t5/Working-With-Services-Knowledge/IdentityNow-Mock-Project/ta-p/208216

Once, you go into the structure of the zip file, you will see a folder called as supporting documents and inside that you will have a file called as Services Standard BeforeProvisioning where you can find the exact details.

I am sure this is available in the official documentation also but not really aware of where it is stored.
Please check and let me know if that helps.

Regards
Vikas

1 Like
17

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