Web Services Connector - Before & After Operations Rules

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

Hello Experts,

I have created a source (web service connector) for an application using custom auth and an API token. Some of the below HTTP operations I have configured (A, B & C) works fine but I need help with setting up the other operations (D, E & F) by creating before and after operations rules. See the following details regarding different endpoints and mapping/config.

HTTP Operations:

A. Operation name: Test Connection
Operation type: Test Connection

B. Operation name: Account aggregation-1
Operation type: Account aggregation
Context URL: /api/v1/users (gets user list)
HTTP Method: GET
Headers: key (Authentication) - value (xxxxxxxx)
key (Content-Type) - value (application/json)
Body (raw): {}
Response Info: Root path: $, Success codes: 2**
Response mapping:
schema attribute: identity, attribute path: identity
schema attribute: username, attribute path: username

C. Operation name: Account aggregation-2
Operation type: Account aggregation
Context URL: /api/v1/users/$response.username$/roles (gets assigned roles of each user)
HTTP Method: GET
Headers: same as above
Response Info: same as above
Response mapping:
schema attribute: name, attribute path: $.data[*][“roleName”]
schema attribute: username, attribute path: username
Parent endpoint name: Account aggregation-1

The above three operations works fine as expected.

D. Operation name: Create Account
Operation type: Create Account
Context URL: /api/v1/users/{username}/roles (creates user if it doesn’t exist and assigns role to the intended user and {username} is a dynamic value from the access request payload).
HTTP Method: POST
Headers: same as above
Body (raw): `{“role”: [“roleName”]} - this would be a dynamic value (entitlement name) from the access request payload.
Response info: same as above
Response mapping:
schema attribute: identity, attribute path: identity
schema attribute: username, attribute path: username

E. Operation name: Add Entitlement
Operation type: Add Entitlement
Context URL: /api/v1/users/{username}/roles (assigns role to the intended user and {username} is a dynamic value from the access request payload).
HTTP Method: POST
Headers: same as above
Body (raw): {"role": ["roleName"]} - this would be a dynamic value i.e entitlement name from the access request payload.
Response info: same as above
Response mapping:
schema attribute: name - attribute path: $.data[*][“roleName”]
schema attribute: username - attribute path: username

F. Operation name: Remove Entitlement
Operation type: Remove Entitlement
Context URL: /api/v1/users/{username}/roles/{role} (removes role from the intended user, {username} and {role} are dynamic values from the access request payload).
HTTP Method: POST
Headers: same as above
Body (raw): {“role”: [“roleName”]} - this is a dynamic value
Response info: same as above

I would appreciate if you could please;
1: Advise on the provisioningPlan rules needed for above three operations.
2: Share the code for before and after operation rules
3: How to pass these dynamic values i.e {username} in the endpoint URLs and {roleName} in the request body?
4: Do you think the following create account provisioning policy should work fine?

Thanks!

{
        "name": "",
        "description": null,
        "usageType": "CREATE",
        "fields": [
            {
                "name": "Name",
                "transform": {
                    "type": "identityAttribute",
                    "attributes": {
                        "name": "username"
                    }
                },
                "attributes": {},
                "isRequired": false,
                "type": "string",
                "isMultiValued": false
            },

            {
                "name": "PassMain",
                "transform": {
                    "type": "rule",
                    "attributes": {
                        "name": "Create Password"
                    }
                },
                "attributes": {},
                "isRequired": false,
                "type": "string",
                "isMultiValued": false
            },
           
            {
                "name": "username",
                "transform": null,
                "attributes": {},
                "isRequired": false,
                "type": "string",
                "isMultiValued": false
            }
        ]
    }
2

Hi

It seems this API’s are straight forward. If username is your nativeIdentity then just out $plan.nativeIdentity$
For roles keep $plan.roles$ if you are maintaining same attributes in the schema use it as it is or else make a changes accordingly.

Make sure create provisioning policy is created to create an account with requested attributes so you can cal them dynamically as mentioned above.

For webservice connector ref please check below url but this configuration is from IIQ both are same just UI is different. Just for understanding how to configure API’s you can ref below one.

Thanks,
Siva.K

1 Like
3

Hi @nhassan ,

Please use the below details, I hope this will work.

D. Context URL: /api/v1/users/$plan.nativeIdentity$/roles
Body (raw): {“role”: ["$plan.role$"]}

E. Context URL: /api/v1/users/$plan.nativeIdentity$/roles
Body (raw): {"role": ["$plan.role$"]}

F. Context URL: /api/v1/users/$plan.nativeIdentity$/roles/$plan.role$
Body (raw): {“role”: ["$plan.role$"]}

Note: Please change the “role” according to your configuration.

In my opinion, the rule is not necessary for this.

2 Likes
4

Hi @Rohit_Sahu and @Sivakrishna1993

Thanks for your help with this, appreciated!.

Let me try all this in sandbox and then will let you know how it goes.

1 Like