SCIM skip GetObject after disable

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

We have 2 (non-compliant) SCIM sources that do not return inactive users either through full aggregations or single user aggregations. This works fine because we do not care about the disabled users on these sources, however, it does present a problem when we try to disable an account on termination. The disable operation works as expected and disables the user on the source, but SailPoint immediately tries to the GET the user record again and that fails, which makes it appear that the disable failed when it did not.

Is there any method to disable the GET operation after the disable OR to consider certain response codes (404 in both of these cases) as a success so that the disable operation can function normally and not look like a failure to our auditors?

We have considered using a Web Services connector for each of these sources so that we have more control over these functions and responses, however, we would prefer to use the SCIM connector and bend it slightly to our will.

Any help or insight is appreciated.

2

Do the auditors care about truthful, validated account data representation? Or augmented representation is good enough?

(e.g. Whereā€™s the bar? A consumer cosmetic mirror or a NASA space telescope-grade mirror for capturing every bit of detail?)

3

Hi Kyle,
Welcome to the Sailpoint Developer Community, I would have to say a custom connector is probably the way to go to resolve this - however I will have a look and see what may be possible with the connector itself.

4

Hi @KL111

Have a look at this

I havenā€™t tried it but it does state the following -

ā€œThe SCIM 2.0 source supports the configuration of a non-compliant SCIM server. In the SCIM 2.0 source UI, on the Relax Configuration sub-panel, enable the Non Compliant Server? option to skip SCIM 2.0 validation for each response from this server. Use this if your SCIM 2.0 Server is not fully compliant with SCIM 2.0 specifications.ā€

This may be what you are looking for :slight_smile:

5

Thank you, @sk8er23. We have both connectors configured as non-compliant because they lack any usable SCIM endpoints other than Users and Groups, however, this does not change the behavior of the disable.

6

Thanks @KL111 for confirming, its good to know its limitations.

7

@IIQUserOnCompass In this case, itā€™s truly cosmetic that we are striving for.

The applications themselves are audited separately (redundantly) but if the account disable shows as failed in SailPoint, we have to provide extensive documentation and it requires multiple additional meetings. If the process merely looked like it was working (and really it is) then that would be sufficient.

8

Do you have an API gateway in your landscape to intercept the GetObject call and craft up a custom response conditionally?

9

Out of interest if you query the connector config via API what features do you have listed? Should look something like this:

ā€œfeaturesā€: [
ā€œPROVISIONINGā€,
ā€œNO_PERMISSIONS_PROVISIONINGā€,
ā€œGROUPS_HAVE_MEMBERSā€
],

10

No, unfortunately we do not.

11

For these two sources it is only Enable/Disable and Provisioning:

"features": [
        "ENABLE",
        "PROVISIONING"
    ],
12

You could potentially try adding the ā€˜NO_RANDOM_ACCESSā€™ feature string to the existing list of features. This indicates the connector cannot support single reads via the getObject method. Iā€™ve never tried this but in theory it may work.

This would however mean the connector would not perform the single get object call after other provisioning operations as well so validation would not happen until a full aggregation occurs.

2 Likes
13

@patrickboston That actually does work! Very cool!

Itā€™s unfortunate that this also removes the ability to do a Get Object on a single user, but thatā€™s really not a problem for our use case. Thank you!

2 Likes
15

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