The integration between SailPoint and BMC Remedy Service Desk enables customers to create incidents and change requests in BMC Remedy Service Desk for the configured operations (for example, Change Password, Request Entitlement and so on) for the configured application. The seamless integration of SailPoint and BMC Remedy Service Desk Service Integration Module eliminates the need to build and maintain a custom integration, and speeds time-to-deployment.

Supported features

BMC Remedy Service Integration Module supports the following features:
• creating a ticket for all provisioning operations that can be performed on Target Application accounts
• getting the status of the created tickets
• creating multiple tickets in Remedy System via IdentityIQ

Supported platforms

SailPoint BMC Remedy Service Desk Service Integration Module supports the following versions of BMC Remedy AR System:
• BMC Remedy AR System 9.1.00
• BMC Remedy AR System 9.0.00

Pre-requisites

• BMC Remedy Change Management Application must be installed
• Ensure that the following software is operating correctly:
-BMC Remedy AR System
-BMC Remedy Change Management Application

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 BMC Remedy eliminates the need to build and maintain a custom integration, and speeds time-to-deployment.

For any IT resources managed by BMC Remedy Service Desk, IdentityIQ automatically creates a trouble ticket within Remedy Service Desk, passing along all relevant identity data and reviewer comments to populate 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 via the Remedy Mid Tier to broker communications between the SailPoint server and the AR System server. 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 IntegrationConfig configured for each target application, service desk request issue to a given remediation/implementation point. Once the IntegrationConfig for Remedy has been loaded into the IdentityIQ server, all change/remediation actions result in the creation of new service desk request.

At the completion of the change control cycle within IdentityIQ, an “Open Ticket” request is made over the appropriate SOAP channel to the Mid Tier. From here change request tickets are opened and the new ticket number is returned to IdentityIQ. The schema for the service request is defined in the IntegrationConfig and allows for the flexibility to transfer complete details on the service desk request. The default settings will create a basic ticket as shown below.

Configuring BMC Remedy AR System for IdentityIQ Integration

This section provides the required information for configuring IdentityIQ to integrate with BMC Remedy Action Request System (AR System). This integration enables IdentityIQ to create Change Management tickets for requested revocations, track ticket numbers in association with revocation tasks, and update IdentityIQ with the status of current Change Management tickets.

The following steps should be performed to modify the default Remedy integration configuration for a specific BMC Remedy application instance.

1. Confirm the default Remedy Change Management Application Web Services exist. This is done by launching the BMC Remedy Administrator, expanding the appropriate server object and clicking on the “Web Services” object.

2. Next, obtain the environment-specific Web Service “endpoint” by performing the following steps:
a. Double-click on the Web Service and select the WSDL tab. Copy the WSDL handler URL into your buffer (For example, Ctrl-C)

b. With a web browser, visit the WSDL URL for the web service by entering the URL into the browser address field and pressing return.
c. Search for soap: address location= to find the endpoint URL. Copy this value. It will be used to replace the endpoint URL in the default IdentityIQ Remedy IntegrationConfig object.

d. Review the Create InputMap section of the WSDL to understand the fields available for the population through the Web Service. These fields should correspond to the fields listed in the section of the default IdentityIQ IntegrationConfig object

3.Once you are familiar with the WSDL, modify the default IdentityIQ Remedy integration using the information collected about the web service.

a. In the element of the integration configuration, modify the username and password entries in the attributes map to contain the credentials required for authentication to the web service.

b. In the element of the integration configuration, modify the provision entry of the Attributes map by setting the endpoint, and, if necessary, the namespace, the prefix, the response element, and the soapMessage attributes (the default values: IdentityIQ Remedy IntegrationConfig):

i. Set the value for an endpoint to the value located in the WSDL earlier.

Note: The value in the IdentityIQ integration configuration must be a valid HTTP URL and have any special characters escaped. The most common change that must be made is to replace all & symbols with &

ii. The value for namespace comes from the targetNamespace attribute of the xsd: schema element in the WSDL.
SailPoint Integration Guide 35

iii. The value for the prefix is the prefix of the XML elements that will be contained in the SOAP response sent by the mid-tier server.

iv. The value for response element should be the ARS form field that corresponds to the id of the form that the web service creates.

v. The value for soapMessage should be the SOAP message body that IdentityIQ will send to ARS. The exact format of this message is a function of the form that is published as described by the form’s WSDL. The XML elements in the soapenv: Body element should be changed to match the ARS form fields for the published web service. Each required ARS form field must have an element in the SOAP message. The value can be fixed or can be a variable that will be substituted using IdentityIQ’s Velocity templating.

The information in the reference section above shows the variables that are provided and the example integration configuration provides examples of how they are used.

Configuring IdentityIQ for BMC Remedy Action Request System Integration

This is intended as an introduction to the configuration needed to integrate IdentityIQ with the BMC Remedy Action Request System. This integration enables IdentityIQ to interact with many of the product solutions that are built on top of the AR System Server including BMC Remedy Change Management, BMC Remedy IT Service Management Suite, and BMC Remedy Service Desk.
BMC Remedy Action Request System Integration

SailPoint provides a default Remedy integration configuration. This configuration implements the integration between IdentityIQ and the Remedy Change Management Application to fulfill creation of tickets based on IdentityIQ access certification remediation events.

The integration configuration must include the following entries:
• endpoint: URL to the web service
• namespace: namespace of the XML returned by the web service
• prefix: prefix associated with the namespace
The integration configuration includes the following entries if the web service side of the integration is configured for authentication using the SOAP authentication specifications:
• username
• password
• authentication
• locale
• timeZone
• status map

The integration configuration includes the following entries if the HTTP authentication is configured:
• basicAuthType: if HTTP authentication is configured the value of basicAuthType is true.
• httpUserName
• httpUserPass
The user must modify remedy integration configuration file with the following entries to create an incident in BMC Remedy Action Request System:
• endpoint
• response element key
• SOAP envelop and body details
• status mapping

The web services and authentication entries are consumed by configuration entries for each web service. They can be positioned either within the configuration entries themselves or as children of the Attributes element. Entries that are children of the Attributes element can be thought of as global values, while entries within the configuration entities can be thought of as local.

For example, if both entries share the same authentication credentials, those credentials might be placed in the Attributes element as peers of the configuration entries and the integration code search the parent entry for the credentials if they are not found in the configuration entries. Conversely, if the configuration entries have different endpoints (are handled by separate web services), each configuration entry specifies the endpoint of the web service to call and any value outside of the configuration entry is ignored.

There are two supported configuration entries for integration with Remedy. These entries are children of the integration Attributes element:
• getRequestStatus
• provision

The values of each are Map elements containing key/value pairings of the configuration data. They contain the specific data needed by the getRequestStatus()and provision() methods of the IdentityIQ integration executor and correspond to Remedy Web Service methods.

The getRequestStatus and provision entries contain the following entries:
• soapMessage (required): full XML template of the entire SOAP envelope that is sent to the web service. The integration code first runs this template through Apache’s Velocity template engine to provide the data needed by the web service.
• responseElement (required): name of the element containing the results of the web service call (for example, the element containing the ticket number opened by the web service in response to the call from IdentityIQ).
• statusMap (optional, see “Sample getRequestStatus entry” on page 37 for an example)
• username (optional)
• password (optional)
• authentication (optional)
• locale (optional)
• timeZone (optional)
• endpoint (optional)
• namespace (optional)
• prefix (optional)

Before a template is sent to the web service, it is processed by the Velocity template engine. The integration code provides different data objects to Velocity for evaluation based on the integration method.

The provision call passes the following objects to Velocity:
• config: the integration configuration for provision, represented as a Map
• provisioningPlan: the data model of the provision request
The getRequestStatus call passes the following objects to Velocity:
• config: the integration configuration for getRequestStatus, represented as a Map
• requestID: the string ID of the request whose status is being queried

Both calls have access to a timestamp variable containing a current Date object and a dateFormatter object. The dateFormatter is built using an optional dateFormat attribute from the config object. If the dateFormat attribute does not exist, the formatter defaults to the pattern EEE, d MMM yyyy HH:mm: ss z.

Sample getRequestStatus entry

Note: The entries contained in the Map are the only required entries. Any authentication information required by this integration is inherited from the parent Attributes element.

Sample provision entry

Note:This Map contains its own web services information. Any authentication information required by this integration is inherited from the parent Attributes element.

Sample scenario

The sample integration scenario is built around a sample system. In the sample scenario SailPoint (IIQ) would be issuing a change request to BMC Remedy Change Management (RCM) based on the results of a scheduled user entitlement and access review. As a result of remediation actions in this account recertification process, IdentityIQ would open change requests to control the flow of the manual remediation process.
Scenario

1. The ComplianceManager1 schedules an access review for a business critical application:
a. The certification is scheduled and assigned to ApplicationOwner1.
b. ApplicationOwner1 receives an email with a link to the Online certification process as scheduled. The link is followed by the open certification.
c. ApplicationOwner1 decides that GroupA on system LDAP should be removed.
d. ApplicationOwner1 decides that RoleA on system RDBMS should be removed.
e. ApplicationOwner1 completes the certification and sign off the process.

2. IdentityIQ evaluates the provisioning plan to enact the remediation requests for the certification:
a. IdentityIQ policy describes the integration execution path for LDAP as being via an automated provisioning system.
b. IdentityIQ policy describes the integration execution path for RDBMS as being via an automated RCM integration.

3. IdentityIQ creates a service request in RCM:
a. IdentityIQ uses the provisioning interface to open a service request within Remedy, passing in details of the changes required to the RDBMS system.
b. RCM responds with the service request number.
c. IdentityIQ stores the service request number for later audit and review.