We would like to utilize the APIs to submit access requests from ServiceNow. We do not own the ServiceNow IdentityNow catalog. The problem we are having is we want to preserve the requester from ServiceNow as the requester in IdentityNow. The behavior we are currently seeing is the requests are being submitted by our service account. This is causing issues with data integrity and with our audit trail and ensuring a requester cannot approve their own request.
I’d recommend for your situations
-
Do the approvals in ServiceNow
-
Add an activity to the beginning of your ServiceNow workflows that will eventually send a provisioning requests to IdentityNow to query for that user’s identity Id using some unique identifier that’s present in both systems. For us, it’s a personnel number.
We would prefer the approvals still to be handled in IdentityNow so all the audit logs are in one place. Also, we want the requests to be available in IdentityNow and in ServiceNow and don’t want to have two versions of the Access Profile (one with approval workflow for IDN and one without approval workflow for ServiceNow).
We are able to look up the identities in IdentityNow using the public identities API and submit requests for the beneficiary, but the requester is listed as our service account.
Hi @kej01s , from my best knowledge, it is not possible to have the SNOW requestor become IDN requestor, since the request is created by the IDN service account.
You may add the SNOW requestor details in the comment field of the IDN Access Request API so at least you capture it somewhere which you can easily see in IDN reports.
HTH!
I’m not familiar with the inner workings of ServiceNow, but if you can create an oauth enabled app on ServiceNow that allows users to login to their IDN account before submitting access requests, then you could submit access requests from SNOW that come from the user.
Check out this doc from SNOW which suggests you can register a third-party OAuth provider: Product Documentation | ServiceNow
You would need generate an OAuth credential in IDN using the authorization code grant type. Authentication | SailPoint Developer Community
This is just a starting point. I don’t know enough about SNOW to tell you how to proceed from here.
Hang on, let’s back up a second. There’s the service account that creates a request, and the identity that the access is requested for. So we have requestor and requestedFor being two separate entities.
I haven’t tested this, but I would imagine that the IdN approval engine is smart enough not to allow users to approve their own access in an access request. The user who submits the request isn’t important, it’s the user who is receiving the access
Here’s an example access request that came from ServiceNow on behalf of another user. Note that requestor and requestedFor are two separate objects.
{
"name": "secWV10HaynesvilleUsersProd",
"type": "ACCESS_PROFILE",
"cancelledRequestDetails": null,
"errorMessages": null,
"state": "REQUEST_COMPLETED",
"approvalDetails": [],
"manualWorkItemDetails": null,
"accessRequestPhases": [
{
"started": "2023-12-12T21:06:25.485599Z",
"finished": "2023-12-12T21:06:35.441416Z",
"name": "SOD_PHASE",
"result": null,
"state": "COMPLETED",
"phaseReference": "sodViolationContext"
},
{
"started": "2023-12-12T21:06:35.693527Z",
"finished": "2023-12-12T21:06:35.795687Z",
"name": "APPROVAL_PHASE",
"result": null,
"state": "COMPLETED",
"phaseReference": "approvalDetails"
},
{
"started": "2023-12-12T21:06:35.868965Z",
"finished": "2023-12-12T21:06:38.974183Z",
"name": "PROVISIONING_PHASE",
"result": "SUCCESSFUL",
"state": "COMPLETED",
"phaseReference": null
}
],
"accountActivityItemId": "238d6b531b6e4c098f63ac7c81796737",
"requestType": "GRANT_ACCESS",
"modified": "2023-12-12T21:06:44.202Z",
"created": "2023-12-12T21:06:25.289Z",
"requester": {
"type": "IDENTITY",
"id": "2c918087802a65bd01803d456238178d",
"name": "ServiceNow"
},
"requestedFor": {
"type": "IDENTITY",
"id": "2c91808382d66ec0018316aa7f454d7a",
"name": "Tyler G"
},
"requesterComment": {
"comment": "Created via ServiceNow Request Item RITM0128125 Requestor Comments: daily job duties",
"author": {
"type": "IDENTITY",
"id": "2c918087802a65bd01803d456238178d",
"name": "ServiceNow"
},
"created": "2023-12-12T21:06:25.289Z"
},
"sodViolationContext": {
"state": "SUCCESS",
"violationCheckResult": {
"message": {
"locale": "en-US",
"localeOrigin": "DEFAULT",
"text": ""
},
"violatedPolicies": [],
"violationContexts": [],
"clientMetadata": {
"identityRequestItemId": "238d6b531b6e4c098f63ac7c81796737",
"identityRequestId": "2dc502fe50b74729a6df7e65d9da5965",
"workflowCaseId": "426f0333fa8c4116a4ceac8ed801cb74"
}
},
"uuid": "48cbf3bf-8be7-4c62-8093-8026e717ba29"
},
"provisioningDetails": null,
"preApprovalTriggerDetails": null,
"description": "WellView 10 PROD Haynesville Users Group",
"removeDate": null,
"cancelable": false,
"accessRequestId": "0f1a1388bdd047b89890bae29c7797ac",
"clientMetadata": null
}
FYI @kej01s
The trick here is that if it was the manager submitting in servicenow, there’s no reason to prompt them for another approval. How do you detect it was the manager and skip the approval (the way we would do it if the request was entered directly in IDN)
Perhaps with an event trigger and a workflow that calls back into servicenow? I’m not totally sure since we do our approvals within servicenow.
We don’t even skip an approval when the manager is the requestor because our auditors don’t have much imagination.
We have people that move around a lot and it would require additional evidence documentation for us to prove at the time of the request that was the manager if they’re not the current one. Like I said, not much imagination
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.