Is it possible to authorize entitlements in "PlainID" before approving/provisioning access in SailPoint?

IdentityIQ (IIQ) IIQ Discussion and Questions
, ,
1

Is it possible to authorize entitlements in “PlainID” before approving/provisioning access in SailPoint?

2

Hi @jaindashing Can you elaborate more on the ask?

3

Hi @rajeshs thanks for reverting.
Is it possible to integrate PlainID with SailPoint for authorization purpose? What i mean is, when we raise an access request for an application’s entitlements we would first want it to be authorized against PlainID (to confirm whether user is actually eligible for selected entitlements based on some policy in PlainID) before triggering approval workflow and provisioning.

Secondly, if the user is eligible for selected entitlements (based on PlainID policy) then we should be able to skip approval workflow for that request. Also, after approval, provisioning will work only for those entitlements which were allowed by PlainID and rest of them should get auto rejected.

such kind of integration is feasible between these two platforms?

4

Hi @jaindashing

I am not an expert in PlainID. We don’t have an Out of the box PlainID connector in SailPoint.

But if we have the API details of PlainID source, we can onboard it as a webservice connector in SailPoint and try the provisioning activity which you are looking for

5

This sounds a lot like how the SAP GRC integration works in Risk Analysis mode. I would suggest looking there for some inspiration on how Sailpoint accomplished that same kind of scenario using GRC for proactive policy checks for users submitting requests for SAP entitlements. Note that this integration requires pretty heavy customization of the LCM Provisioning workflow and various subprocesses to perform the GRC policy checking.

image
image1505×854 92.4 KB

https://documentation.sailpoint.com/connectors/identityiq/sap/grc/help/integrating_sap_grc/integrating_sailpoint_with_sap_grc.html

6

Hi @jaindashing

I am not aware of PlainID working but I was thinking whether we could try leveraging AdvancedPolicy to restrict the user from raising request.
For instance, write the Rule (In Advanced Policy) to trigger PlainID API(If they have any) or any other mechanism to check whether they are authorized to raise a request or not. And if they are not authorized throw a policy violation restricting the user from raising the request. This will block unauthorized users from raising request instead of rejecting each unauthorized request.

7

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