Basic Configuration
The integrated solution speeds the detection and remediation of identity management issues that increase the risk of compliance violations or security breaches, such as orphaned accounts, policy violations, and inappropriate access privileges. Organizations can take advantage of a centralized approach spanning thousands of users and hundreds of resources to strengthen IT controls and provide proof of compliance to auditors and executive management. The seamless integration of SailPoint and ServiceNow eliminates the need to build and maintain a custom integration, and speeds time-to-deployment.
For any IT resources managed by ServiceNow Service Desk, IdentityIQ automatically creates a trouble ticket within ServiceNow Service Desk, passing along all relevant identity data and reviewer comments to populate the ticket and can also send an attachment with the ticket.
To ensure revocation requests get delivered and implemented, IdentityIQ manages all remediation and revocation requests within a guaranteed delivery model.
To determine the status of user accounts, IdentityIQ performs closed-loop audits on remediation requests and compares the actual state of user privileges with the original change request. If the request is still open, an alert will be sent to the reviewer for prompt action and closure.
The integration itself has been designed to be quick to install and easy to use. It makes use of Web Services for communications between the SailPoint server and the ServiceNow. On the backside of a user recertification, policy remediation action or access request action, the IdentityIQ server will direct provisioning and service desk requests to the configured implementers. Based on the connector configured for each target application, service desk request are issues to a given remediation/implementation point. Once the IdentityIQforServiceNowServiceDesk file for ServiceNow has been loaded into the IdentityIQ server, all change/remediation actions result in the creation of new service desk request as shown in Service request creates ticket using SailPoint Cart JS API. Incident and change request creates ticket using import set table APIs and transform maps.
The IdentityIQ for ServiceNow Service Desk generates tickets for provisioning requests. These tickets generate service requests on sc_requesttable for REQ and sc_req_item table for RITM, incidents on incident table, or change requests on the change_request table. The module fetches the status of ticket by using the direct web services of target tables that is, sc_request (in case of tracking status for REQ) / sc_req_item(in case of tracking status for RITM), incident or change_request and updates the SailPoint IdentityIQ database with the status.
ServiceNow Service Desk integration supports configuration only through IdentityIQforServiceNowServiceDesk.xml file which must be imported.
Basic Flow of Service Request
IdentityIQ creates ticket by requesting a Catalog item on ServiceNow. Each application on IdentityIQ has a Catalog item defined on ServiceNow. IdentityIQ calls ServiceNow's Web Service requesting the Catalog Item. The Web service creates a Cart and adds the Catalog item to the cart. The Catalog item has Catalog Variables. The information is taken from the IdenityIQ's request and passed on to these Catalog Variables. The Catalog Item has a Workflow attached to it. After adding Catalog Item to the cart, Cart is submitted. Submission of cart triggers the Workflow. The workflow creates a task by passing the information from Catalog Variables to Service Request. The Requested Item ticket number is returned as the response which is later used to check the status.
Depending on the workflow configuration, the task is assigned to the user (group or individual), who then performs the action which results in change in the State of the Requested Item.
For LCM flow, when ticket type is serviceRequest, REQ would be created per Identity and RITM would be created per application associated with Identity.
Basic Configuration of Service Request
-
Create Catalog items on ServiceNow for each application on IdentityIQ that user wants to manage using IdentityIQ for Service Desk.
-
The opened_by and requested_for fields receives values using the default Rule (Plan Initializer script) in ServiceNow Configuration file. Modify the Plan Initializer script as per requirement to populate the fields.
For example, see requested_for catalog variable in the default Catalog item (SailPoint Access Request).
If the user is not present on ServiceNow, then ‘opened_by’ and ‘requested_for’ fields will display default ServiceNow Administrator.
-
Provide the mapping between Application and Catalog item in the catalogItem field in ServiceNow Integration Configuration file.
The value is sys_id of catalog Item.
For example:
<entry key="Procurement_System" value="8053818edbffb300e90690b3db9619c4"/>
-
By default,under provision request will work for REQ. In order to use RITM, change the request tag key and value, as shown:
<entry key="track_ritm" value="true" /> -
Verify the default mapping between ServiceNow’s Request (REQ))/(RITM) Status field and IdentityIQ status in ServiceNow Integration Configuration file. This is used to update the status of IdentityIQ line item.
-
Create and publish a workflow and attach it to the respective Catalog Item to handle the Requested Item (RITM).
The workflow must be able to create a Catalog Task.
For more information on procedure for creating the workflow, see the following link:
Refer to the default workflow given with the SailPoint for Service Desk application . Login with the admin user or user with workflow_admin to create or update the workflow.
-
The default workflow, in the Run Script activity has a scripting logic to get values from Catalog Variables and assign to the fields of Service Request and Requested Item. Use that or modify accordingly. Configure the Workflow as per requirement.
-
The State of Requested Item (RITM) changes when the State field of the Task changes due to the Workflow defined on the Catalog Item. The Request State on the Service Request changes due to the default ‘Service Catalog Request’ workflow.
-
If some records or columns are not displayed with Minimum permission user, add the specific ACLs to view the records.
For more information on procedure for creating the ACL, see the following link: