All objects not passed with Add Entitlement operation

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

Hello

I’m trying to set up a web services source in IdentityNow for Everbridge and would need some advice.

These are the http op’s I’m currently doing, in the below order:

  1. Test
  2. Account aggregation, endpoint
  3. Group aggregation, endpoint
  4. Get object, endpoint
  5. Create Account, endpoint
  6. Add Entitlement, endpoint
  7. Remove Entitlement, endpoint

Everbridge API doesn’t have a separate endpoint to add a role/entitlement. I would need to use the Update User endpoint to pass the roleIds in the body of the request.
The request also requires to include the email, firstName and lastName. Since the http op is PUT, I also want to include the ssoUserId just in case to avoid it being overwritten with a blank and users not being able to sign-in.
This is the body I’m currently passing along with Add Entitlement:

{
  "firstName": "$plan.firstName$",
  "lastName": "$plan.lastName$",
  "email": "$plan.email$",
  "ssoUserId": "$plan.employeeNumber",
  "roleIds": [
    $plan.roles$
  ]
}

The only thing that reaches the endpoint currently is the requested roleId.
Is it not possible to pass the identity data together with the entitlement info in the same request with the Add Entitlement op?

I’ve also tried including the roleId in the Create Account op with the same body as above, but the opposite happens. Only the identity data gets passed, roleId does not reach the endpoint.

Any ideas/thoughts what I could look into?

Thanks in advance.

1 Like
2

Hello Sander,

Do you have the " Create Account With “Ent” Request" option checked? Try to have that option selected and then try to pass the “roles” in the create operation.

For the add entitlement operation, do you have an update provisioning policy in place to get any additional identity attributes in the plan?

3

Do you have the " Create Account With “Ent” Request " option checked?

I completely missed this, thank you! I have set it to true now.

I realised I was also sending the roleIds incorrectly in the body:

"roleIds": [
    $plan.roles$
  ]

This was sending it as array in an array. I’ve now changed it to:

"roleIds": $plan.roles$

After these changes, I was able to create the account with the role in the service.

For the add entitlement operation, do you have an update provisioning policy in place to get any additional identity attributes in the plan?

I have all the attributes I want to send mapped in the Provisioning policy/Create account. Is this what you mean?

4

Hello Sander, are you still facing the issue when trying to add an entitlement? If yes, then try to add the those identity attributes in a update provisioning policy like you did for create. The provisioning policy should have the usage type as “usageType”: “UPDATE”

1 Like
5

Yes, the adding entitlement issue is still there.

I did create a Provisioning Policy with the Update usageType and the same attributes as in Create, however I’m still only receiving the roleIds to the endpoint.

Is Update the correct usageType for Add Entitlement operation?
I couldn’t really find any documentation explaining to which Operation Type all the usageTypes map to.

6

Hi @sanderwise

Yes, It is not possible to add to identity data attributes in ASSIGN usage type without before provisioning rule as far as i know. May be you could try to setup the provisioning policy such that you do not use the same attributes in provisioning policy but others like for email you can use like below

{ "name": "email1", "transform": { "attributes": { "name": "email" }, "type": "identityAttribute" }, "attributes": {}, "isRequired": false, "type": "string", "isMultiValued": false }

And then try to use this email1 in the operation body. I have seen this approach doing the trick for update provisioning policy to sync additional attributes but have not tested it for ASSIGN usageType.

If this approach does not work for you then you have another option with WebService before operation rule which you can configure on the add entitlement and remove entitlement operation.

In this rule, then you will need to make a GET API call to the target application or ISC to get the current email and other attributes from the back-end then populate them into the json body before sending it.

That should do the trick for you.

Please let me know if there are any queries or need assistance, happy to support.

Regards
Vikas.

1 Like
7

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