SCIM Server CheckedPolicyViolations fails with no policies supplied

IdentityIQ (IIQ) IIQ Discussion and Questions
1

If you invoke the /identityiq/scim/v2/CheckedPolicyViolations SCIM API without a policies attribute then no policies are checked.

The API does not support checking all of the policies, if I supply the request with a policy then the check happens and I get a violation, removing the policies attribute to check all the policies, then none of the policies are checked.

For example this returns a policy violation on the Mainframe SOD policy:
{

"identity": "22699291",

"plan": {

    "value": {

        "accounts": [

            {

                "application": "AUR Active Directory",

                "attributes": [

                    {

                        "name": "memberOf",

                        "op": "Add",

                        "value": "CN=my....."

                    }

                ],

                "instance": "null",

                "op": "Modify"

            }

        ]

    },

    "type": "application/sailpoint.object.ProvisioningPlan+json"

},

"policies": [

    "Mainframe SOD Policy"

]

}

Where as this returns not policy violations:
{

"identity": "22699291",

"plan": {

    "value": {

        "accounts": [

            {

                "application": "AUR Active Directory",

                "attributes": [

                    {

                        "name": "memberOf",

                        "op": "Add",

                        "value": "CN=my....."

                    }

                ],

                "instance": "null",

                "op": "Modify"

            }

        ]

    },

    "type": "application/sailpoint.object.ProvisioningPlan+json"

}

}

There is no way to check all the policies, unless you list every single policy in the policies attribute, we have too many policies to do this and it makes the json requests huge.

2

That’s a bummer. A thought that comes to mind is maybe to launch a workflow with the /LaunchWorkflows SCIM endpoint. I believe there is a subprocess inside of LCM Provisioning that performs violation checks. Or make a custom workflow that makes the necessary calls and make sure to output any violations found.

3

Thanks for the input Patrick.

/LaunchWorkflows works pretty nicely, and not that hard to setup a workflow do do the checks; however, I discovered if was my SOD policy that was causing the issue. The Policy was marked as inactive, so if you call /CheckedPolicyViolations with an inactive policy, and that policy is explicitly named in the policies attribute, then the API it will check it and give you the result. If you don’t name the policy explicitly then its not checked. So there is a search in there for active policies if you check everything.

So I guess I found a feature, you can check an inactive policy if its named explicitly, could be good for testing.

In my case the /LaunchWorkflows might be better as I’m not sure the application calling the service will be able to supply the identity name, maybe just an account and role name.