Integrating IdentityIQ with TeamDynamix

IdentityIQ (IIQ) IIQ Community Knowledge Base
,
1

Introduction

This articles explains how IdentityIQ can be configured to provision and aggregate people in TeamDynamix, an ITSM (ticketing) system.

The implemented functionality includes:

  • aggregating and provisioning people, including group memberships, application assignments, and security role assignments
  • aggregating applications
  • aggregating groups
  • aggregating security roles
  • aggregating accounts (departments)
  • partitioned aggregation of people

Integration Choices

TeamDynamix is a cloud service with a REST API, making the Web Services connector a good choice for integration.

Within TeamDynamix, a person may be associated with one or more “applications”. They may also have a role on one or more “organizationally-defined applications”.

Each of the TeamDynamix applications could be modeled as an IdentityIQ application, perhaps using the MultiPlex Connector. However, the only information of interest is the association to applications and the role assignments on org-applications. To simplify the integration, the associations and role assignments are aggregated as multi-valued attributes in a single IdentityIQ application.

Implementation Challenges

The first challenge is obtaining a token from the “loginadmin” endpoint. The endpoint accepts the ID and Key in JSON format, but returns the raw token in the response body. That is, the token is not encoded in JSON and the Web Services connector won’t accept that.

To bridge this gap, a proxy endpoint is implemented that passes the ID and Key through unchanged on the call, but encodes the token in JSON in the response. For convenience the proxy endpoint is in a Java class that is then included with the IdentityIQ build. That way a separate Tomcat instance is not needed.

A second issue is that the API rate limiting doesn’t match what the connector is expecting. The API returns a header indicating when the limit will be reset in IMF format. eg:

X-RateLimit-Reset: Mon, 02 Sep 2024 08:49:37 GMT

The connector is expecting a Unix timestamp. eg:

To bridge this gap, more proxy endpoints are implemented. The endpoints pass requests through unmodified, but convert the response headers to suit what the connector is expecting. A connector “Before Operation” rule is used to redirect calls to the proxy endpoints.

A related issue is that the connector backs-off much longer than necessary when the API returns a 429 “Too Many Requests” status. This is a problem when aggregating people, where a GET call is required for each person and the rate limit may be hit many times. To avoid this problem, the proxy endpoint is enhanced to insert delays when the API is approaching the limit so as to avoid hitting it.

Another issue is that account aggregation can be quite lengthy if there are many people. This can be improved by enabling partitioned aggregation and spreading the partitions over multiple application servers.

Having multiple aggregation partitions running in parallel on one/each application server doesn’t help, however, as the API rate limit is applied per-IP-address. This isn’t a problem per-se, as the multiple threads will just proceed at an overall rate limited by the API.

It does mean that partitioned aggregations for other applications will have to wait while the TDX aggregation is hogging the configured threads. A work-around is to wait for the aggregation task to create the partitions, then have a job that re-assigns them to an alternate Request Definition configured for one thread on each application server. This solution could be characterized as a kludge, but I haven’t come up with anything better.

Note to SailPoint: It would be cool if an aggregation task definition could specify the request definition to use.

Outcome

We are managing 55,000 people in 14 TeamDynamix applications. A partitioned account aggregation takes 4.5 hours.

Take-aways

  • Proxy endpoints are a convenient way to bridge gaps between the Web Services connector and vendor APIs.
  • The integration artifacts are attached.

[Application-TDX.xml|attachment](upload://waKqfPrbnz83DMHlWfNBBZD7PrH.xml) (85.5 KB) [TDXProxyResource.java.txt|attachment](upload://qosx5mhWhJE68VN0NYFiIJNKQ10.txt) (28.0 KB) [Collateral-TDX.xml|attachment](upload://iApDBx67ZdKYYwJM3kte9gARajP.xml) (35.6 KB)

1 Like