Installation & Configuration Guide
Integrating with ServiceNow Service Catalog
IDN Q&A (Manager approvals, widget, authorization)
Question/Query:
A customer has several questions regarding this integration:
- They have observed that when creating an Access Request in SNOW Catalog, the "requestor" of the Access Request in IDN shows as the service account used to connect SNOW-to-IDN and not the actual identity that made the initial request. Is this normal? Is there a way to make the requestor in IDN show as the actual identity name which made the request in the catalog, and not the service account name?
- We are confused on the authorization flow and could use some clarifications on the following points:
a. What does the end user experience look like for this flow? End users will obviously be authenticated into ServiceNow, but then do they need to authenticate into IdentityNow?
b. What credentials will be used for this authentication into ServiceNow? We have SSO enabled in our tenant, so will they leverage that or will they need local ServiceNow credentials?
c. After authentication into ServiceNow, does the user stay in the catalog integration for the actual access request submission in the catalog?
d. Could you please clarify the expected value for the field "OAuth app name for Authorization code flow"? How and where do we obtain this value? - Аfter authorization, will the requester of the request be pushed to IdentityNow? The use case here I am trying to understand is the following:
a. Manager submits access request for an access profile requiring manager approval and access profile owner approval
b. Will the request be auto approved in IDN at the manager level because the manager submitted the access request? Or will the manager be required to go into IdentityNow to approve the request?"
Answer/Solution:
- This is normal behavior. IDN automatically populates the “requested by” element using the identity context that invoked the API call. AFAIK, there is no means of altering this.
- a. The general flow for customers of this integration does not involve the Sailpoint UI at all. Users make their requests in SNOW, managers approve requests in SNOW, then IDN provides fulfillment of the requested access.
b. How users authenticate into SNOW does not change.
c. Yes, the entire request process is performed in the SNOW catalog.
d. Generally this field is blank, as OAuth client credentials are being used. I’ve not seen any customers using custom OAuth authorization flows for this integration, but any that did would use this field to facilitate that process. - No, the purpose of this integration is to move the user access request experience entirely into SNOW.
a. Most customers of this integration configure the IDN catalog objects (roles & access profiles) to have no manager approval required, as they want these to happen in SNOW. If a secondary approval, e.g. application owner, is desired, that is configured in IDN. The IDN flow will execute only once the SNOW flow has completed and the request has been passed to Sailpoint for fulfillment.
b. No, if the catalog object had an associated “Manager Approval” flow defined, it would NOT be auto-completed because to Sailpoint, the “requestor” is the service account that connects SNOW to IDN. This is why we advise not to configure Manager approval flows in IDN for catalog objects that SNOW users will request.
Additionally, on Setup page there is an option OAuth flow, where you can select “client_credentials“ and “authorization_code”
When it’s selected “client_credentials“ it will work as above described, for IdentityNow all new access requests will be done as one service account requestor.
When you select authorization_code, then you need additionally configure new OAuth client on ServiceNow side. It’s described here: Configuring ServiceNow for Integration. As a result - you will see next screen on the first page:
If you want to have as a requestor - name of the specific user, you need to sign in into IdentityNow inside of this Manage Access page, so Manage access page will contain info about who is it as IdentityNow user.
You could ask - why it’s not possible to use existing user’s session if you sign in into ServiceNow via SSO, because in this case there no info about who you are as a user in IdentityNow.
When it’s selected OAuth flow = authorization_code, all approvals logic should be made on IdentityNow side.
Follow-up questions from customer:
- The scenario is as follows:
a. They select OAuth Flow = authorization_code
b. The end user logs into SNOW using SSO (its the same SSO Provider they use for IDN)
c. The end user navigates to the Manage Access screen in SNOW and is presented with the message “Before you can make an access request please sign in with IdentityNow credentials“. The user clicks “Sign in via IdentitNow user”
d. Is the user’s browser redirected to IDN for authentication? Or does the user browser remain in SNOW?
e. If the user has already signed into SNOW via SSO, and they use the same SSO for IDN, what happens when clicking the “Sign in via IdentityNow user” button? - Can the “Manage Access” link or widget be removed from the SNOW Catalog home page? If yes, how is that done? (See attached screenshot):
- In the following scenario:
a. SNOW Catalog is configured for manager approval
b. After the user makes the access request in SNOW Catalog, does the approver (manager) receive an email from SNOW? or from IDN?
c. What does the SNOW Catalog Approval UI look like? The customer is unable to find this in the documentation of the SNOW Catalog Integration - Does SNOW Catalog support auto-approvals when the requester is the same person that must approve? For example, if a manager requests access on behalf of a direct report, can SNOW auto-approve the manager-level approval?
- Does IDN record or audit the approvals (or rejections) made in SNOW (such as the SNOW manager-level approval)? If auditors need evidence of the SNOW approval, can they obtain that from IDN? or do they need to run a report in SNOW?
- In the following scenario:
a. SNOW Catalog is configured for manager approval
b. An Access Profile in IDN is configured for Governance Group approval
c. The manager is also a member of the Governance Group
d. The manager makes an access request in SNOW Catalog for a direct report
e. Will both the manager approval (in SNOW) and Governance Group approval (in IDN) be auto-approved? - In the following scenario:
a. SNOW Catalog is configured for manager approval
b. An Access Profile in IDN is configured for Access Profile owner approval
c. The manager is also the Access Profile owner
d. The manager makes an access request in SNOW Catalog for a direct report
e. Will both the manager approval (in SNOW) and Access Profile owner approval (in IDN) be auto-approved? - The customer has setup several Roles and Access Profiles in IDN
a. Certain Access Profiles should not be requestable in IDN or SNOW Catalog. These Access Profiles have their names begin with the prefix “NonRequestable”
b. The customer has configured the SNOW Catalog filters to only display Access Profiles which are requestable. However these filters are not working. SNOW Catalog shows all Access Profiles as requestable
c. They have tried with these search filters and they work in IDN Search, but they don’t work in SNOW Catalog. Is this a possible bug? or are they using incorrect search filters?@entitlements(name:"") NOT "NonRequestable-" @entitlements(name:"") ! "NonRequestable-" name ! co"NonRequestable-" requestable:true AND NOT name:"NonRequestable-" NOT name:"NonRequestable-" ! name:"NonRequestable-" not name co "NonRequestable-" nameNOT LIKENonRequestable- NOT entitlements.name"NonRequestable-" entitlements.name NOT ("NonRequestable-") name NOT ("NonRequestable-") @entitlements(name:"") co NOT "NonRequestable-*"
Follow-up answers for customer:
- When user clicks on button “Sign in via IdentityNow user“ it will be shown a pop-up where it should be shown IdentityNow Sign-in form. If on the specific IdentityNow org is configure SSO for example via Active directory has already an active Active directory session - it will be automatically processed and as a result - this pop-up will be closed and ServiceNow will receive access + refresh tokens from IdentityNow.
- It’s possible via editing Service Portal configuration and its pages: Product Documentation | ServiceNow
- In this case depends on configuration of ServiceNow instance, user should receive notification from ServiceNow. More details: Product Documentation | ServiceNow. To be able to approve the request, user should have a custom role approver_user. This page will look like:
- For now it works like you described, when requester is a manager - this step is skipped.
- It’s more related to ServiceNow functionality.
- For now it’s supported only manager’s approval on ServiceNow side. Any additional approvals are not supported now.
- Same as for 6.
- On Setup page there are 2 fields that can additionally apply custom filtering:
In this particular case it will be:
Follow-up questions from customer:
- The customer wants to change the look & feel of the SNOW Service Catalog UI to match the native SNOW UI, and also to add more search capabilities. Is this customization supported by SailPoint?
- For manager approvals in SNOW, where does the manager information come from? (I’m assuming this comes from IdentityNow, right?)
- When a request is rejected by the manager in SNOW, what type of notification/communication is sent by SNOW? Does it send an email to the requestor and requestee?
- When a request is rejected by the manager in SNOW, what type of notification/communication is sent by SNOW? Does it send an email to the requestor and requestee?
- When a request is rejected by the manager in SNOW, what type of notification/communication is sent by SNOW? Does it send an email to the requestor and requestee? In this case what happens in SNOW?
Follow-up answers for customer:
- In general, OOTB application doesn’t provide an option for extending it. You have an option to changed some fonts/colors via editing template styles, but it requires some ServiceNow developer knowledges.
- On ServiceNow side each user could have a manager. If it’s enabled manager’s approval on ServiceNow side - then user’s manager on ServiceNow side should make an approve.
- As I see for now, SNOW sends some default email notification for the requestor.
- Periodically ServiceNow pulls info about the status of correlated access requests in IdentityNow, if it’s changed - the status of the ticket in ServiceNow will be changed, and ServiceNow will send default email notification.
- In this situation, manager could approve or reject pending request. Requestor could cancel it. If requestor cancel it - SNOW ticket will be closed. It will not be possible for manager of terminated manager to approve/reject it.
Request from Service Catalog Active instead of Closed
Question/Query:
When the ServiceCatalog makes a request to IDN for a disconnected system, a new ServiceDesk ticket is generated. When that generated-ServiceDesk ticket is closed, the original request from the ServiceCatalog should also be closed, but instead it remains Active. Os there any configuration needed to occur for this functionality to work?
Answer/Solution:
I checked with the customer to check any ticket if the ticket status in Service Now after 1 Day is passed after placing request in Service Now and processed in IDN. Client confirmed that the original ticket was closed.
Issue with profiles/roles selection
Question/Query:
Customer is experiencing an issue with the Service Catalog plugin for IdentityNow, it doesn’t retrieve any access profile, role, etc. User selection is OK, but it fails when it comes to profile/role selection. They have checked the PAT password, and even generated a new PAT, without any result. Apparently, the logs don’t show anything specific.
Questions from our side:
Could you clarify which version of Service Catalog app is used now by the customer? We assume that it’s lower than 2.3.24. (Answer from customer: 2.3.20)
Answer/Solution:
The resolution of this issue would be upgrading to version 2.3.24. There is a ticket with description about this issue. If the customer can’t make an upgrade due to some reasons, there is a description how to fix it manually:
- Type “Script includes“ in the left sidebar.
- Find record by name: SP_SPNT_SNOW_INT_GetOwnerAndSourceList, open it and find all matches
"requestable:'true' AND enabled:'true'" and remove single quotes around true. Lines 8, 29 - Find record by name SP_SPNT_SNOW_INT_GetAccessListREST, open it and find all matches "requestable:'true' AND enabled:'true'" and remove single quotes around true. Lines 42, 84
- Find record by name SP_SPNT_SNOW_INT_GetRolesAccessProfileDetails, open it and find all matches "requestable:'true' AND enabled:'true'" and remove single quotes around true. Line 73
Non-Requestable Roles Available in Remove Access Screen
Question/Query:
Customer has some birthright roles in their org that have been marked as non-requestable (check unchecked). As a result these are not visible in the servicenow catalog integration UI when requesting access, however, if a user goes to the Remove Access Screen they can see these roles and can request for their removal.
Answer/Solution:
We investigated this case. Unfortunately, we cannot provide an easy fix or workaround. We created a story to triage and deliver it in some of the next releases and it's already part of our roadmap.
Request not available for a cancelled role
Question/Query:
While customer was running a request test, they found that if they cancel a request for a role by declining approval, it is not possible to re-apply for the same role later.
Answer/Solution:
In general, to provide changes for the customer, we need to make changes in the app and introduce them as a new version. If it’s super urgent, they can manually change the logic:
- Go to Script Includes
- Find script SP_SPNT_SNOW_INT_AccessValidationREST
- Add additional condition to exclude items with state “CANCELLED“ on line 72
ServiceNow Catalog Access Request Email
Question/Query:
- Customer is using a ServiceNow Catalog Integration for Access Request, but the issue is whosoever is requesting an access, the email is getting from the same or only the one name as a requestor. For example, person X is the one who is requesting an access, but the email states that Person Y has requested the access for the identities. Is there anything need to be changed in configuration?
- Also, Managers cannot see the Direct Reports when they are logged in, it is mentioned in the document.
- What would be the “OAuth app Name” for Authorization code flow when using OAuth Authorization flow as steps are not mentioned in the document. Do we have a guide where clients can use step by step instructions as how to set up OAuth Authorization flow?
-
The customer’s requirement is requesting an item from SNOW catalog which is working fine, but after manager approvals/skipping manager approvals from SNOWcatalog side, it waits for the approval from IDN UI which not expected here as in this case SNOW catalog should handle the request and approval flow.
Answer/Solution:
- There are two ways how you can configure the integration between SNOW and IDN in regards to Authentication/Authorization and they are controlled by configuration setting called "OAuth Authorization flow" on setup page
client_credentials - Uses a dedicated user (integration user) which is doing all the requests from IDN to SNOW. I would assume that this is situation with this customer and “Person Y“ is the integration user (please confirm). This is very common approach for integration of two systems, The only downside is that all processing in IDN happens with this user and thats why Person Y receives this email from IDN. P.s. SNOW also sends such confirmation email, so if you configure a dedicated integration user, essentially nobody will see the email from IDN, so the issue doesn't exists in a way
authorization_code - This approach makes it possible to do requests to IDN on behalf of the logged in users in SNOW. With this approach this email will be sent to the exact person who did the request. The only downside here is that every user needs to contest/agree explicitly on it. There is a popup message each time user wants to do a request. *for some customers this is annoying
Customer needs to play around with both approaches and decide which one fits better - Еssentially every user needs to have his manager (manager field) configured in sys_user table - in that case the manager will see all users that have direct reference to him.
- We have an internal document with explanations and screenshots, unfortunately it is not part of official documentation
- It`s quite common requirement and it make sense that either ServiceNow or IDN handles the approvals (not both). In the case of the customer, it seems that IDN access objects (roles, access profiles) are configured to have approvals. I really cannot comment on how to properly configure it on IDN side. Thats a question to IDN team. Maybe it's better to open a new ticket about it and assign it to them.
Requested for" is populated with "Requestor" in ServiceNow
Question/Query:
When opened_by != requested_for we display name of requested_for user in the row with title Requestor. The customer is expecting to see the name of the person for whom the request is made in “Requested For” section.
Answer/Solution:
The only way how it can be solved - it’s to change opened_by value when REQ is created, but I don’t think that it’s right way, because who created request and for whom it could be created could be different. So our vision - it’s expected behaviour according to the template, and it’s not a part of Service Catalog app. So I don’t think that we can make changes here.
Redirect URL
Question/Query:
Client is configuring SNOW Catalog integration with IDN. It requires an Authorization Code from IDN for access requests. After selecting Authorization Code generation on IDN, it requires a Redirect URL. What should the Redirect URL be? Can’t find it on connector document.
Answer/Solution:
Redirect: https://{{SERVICE_NOW_INSTANCE_HOST}}/oauth_redirect.do ({{SERVICE_NOW_INSTANCE_HOST}}) - hostname of ServiceNow instance
Only AD Roles are available/visible in ServiceNow Catalog Portal
Question/Query:
Customer has many roles in their DEV instance but only AD roles are showing up in ServiceNow portal.
Answer/Solution:
In Service Catalog app are displayed only roles that are enabled and requestable in IdentityNow. It says only AD roles are available, but it’s because they are first in the list. Please, try to make more specific filtering and apply search by name. For example Name = SAP. You will see another list of roles.
State update not completed in SNOW
Question/Query:
- User raises request in IDN
- First level Approval done in SNOW
- Second Level approval done in IDN
- Provisioning success in IDN
- But in SNOW item is in pending state
Answer/Solution:
In general, there is a timer once per day to fetch info about changed status of the request on IdentityNow side. If it does not work, then we need to debug the specific RITM and its details. How to do this? You can check RITM workflow context. How to do this - Find RITM details and click on link Show Workflow.
Request Integrity issue
Question/Query:
Working on SNOW-IDN catalog integration demo for a customer. They are specifically interested in looking at request integrity for the entire flow:
- User raise request in IDN
- Approval done in SNOW
- Provisioning failed in IDN due to some connection error
- But in SNOW is shown as successful and completed. Looks like step 4 is not what is expected. End user thinks that it is successful but in reality it is not. How do we tackle this? Also in IDN is there a way to link request created in IDN with request ID generated in SNOW?
Answer/Solution:
We can see that the status is Completed. We need to check the tech details of this request (debug API call).From the user perspective I see your confusion, but technically maybe there is mismatching on IDN side. Technically such request in IDN should have status ERROR.
Issue with Sunset Date format
Question/Query:
Customer has recently upgraded “SailPoint IdentityNow for Service Catalog v2“ v.25 in DEV and TEST. During regression testing, an issue was encountered where RITMs errored out as "Failed creating access request ( Bad Request)" when Sunset/End date is entered in the request. Upon investigation, it’s failing due to Bad Request (error code=400) on SailPoint API while processing through the SP_SPNT_SNOW_INT_CreateSailpointAccessRequest workflow. Based on this, we found out that there is an issue in the date format of the End Date. Please see attached file for the summary and details of the analysis.
Answer/Solution:
It looks like this critical issue the customer is facing is very strictly isolated - we haven’t received such complaint from other customers. That being said, most likely they are using some not general Date/Time format in their IDN Tenant. Adding 'T00:00:00Z' on line 69 in “SP_SPNT_SNOW_INT_WORKFLOW_CreateAccessRequest” script include fixes the issue but is not in our code base, so our assumption is that in the past somebody helped them with this workaround and it was fixed locally on their ServiceNow instance. When they recently did an upgrade, there is a high chance that it was overwritten.
