Integrating with ServiceNow Service Catalog
Question/Query:
A customer has several questions regarding this integration:
Answer/Solution:
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:
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?
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?
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:
In this particular case it will be:
Follow-up questions from customer:
Follow-up answers for customer:
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.
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:
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.
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:
Question/Query:
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:
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.
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
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.
Question/Query:
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.
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:
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.
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.
Client installed the plugin without selecting "load demo data" because it is a production environment and best practices state that demo data not be included in production. Unfortunately, we received an error stating "Cannot connect to SailPoint Server." until we repaired the application with the demo data loaded. This should be resolved so that it is no longer required to select that option when installing in production.