Java applications like IdentityIQ support a variety of deployment architectures. Here are given some recommended architectures:
There are many different architecture patterns for IdentityIQ deployments. This article includes illustrations of a variety of different architectures along with a description of each architecture and an explanation of why it is specifically recommended, not recommended, or not supported.
These response-time statistics apply to any selected architecture as benchmarks for system performance:
| Data Block Size | Response-Time Statistics |
| Average round-trip ping time for a 1k data block from all application servers to the database | 300 Microseconds or less |
| Average round-trip commit time for a 1k data block | 9 ms or less |
| Average round-trip commit time for a 4k data block | 17ms or less |
| Average round-trip commit time for an 8k data block | 20ms or less |
Recommended Architectures:
Single Facility Architecture: Standard “2 Tier” Enterprise Web Application Architecture:
This is what JEE architects call a “two tier enterprise web application architecture.” It separates the users from the web servers with a firewall. It does not separate the application servers from the relational database with any LAN or WAN network traversal. All network components, including the UI Servers, Task Servers, and Database Server, reside in the same data center, preferably on the same Gigabit-Ethernet or faster network segment. This type of architecture is recommended for use with IdentityIQ.
Database Architecture with Storage Area Network (SAN):
For best results, IdentityIQ requires that you use an architecture that is a two-tier enterprise web application with a SAN (storage area network) supporting the database. We recommend this type of architecture because it has been successfully used by other customers and works well with IdentityIQ. The SAN fabric must reside in the same data center as the IdentityIQ application server hardware. The SAN fabric should provide the necessary response times of less than 9 milliseconds, round trip, to commit 1k of data from the application servers.
Disaster Recovery Support: Active/Standby Deployment in Two Data Centers:
This “two data center architecture” is composed of a Primary or Active data center and a Secondary or Standby data center. The database layer replicates the data over the WAN in the background so the data of the primary data center is backed up in the secondary data center. This type of architecture IS RECOMMENDED for use with IdentityIQ, provided the following conditions are met:
- The database replication scheme is a one-phase commit, not a 2-phase commit where the primary blocks until the secondary has committed the transaction. You can request DBA to configure database replication with 1-phase commit.
- Since Sailpoint support Active-Passive architecture, so The Task servers in the secondary data center do not have their application servers running when the primary data center are in use (so data is not independently updated and manipulated in the secondary data center).
- The UI servers in the secondary data center do not have their application servers running when the primary data center is in use (so users cannot interact with and therefore directly modify any data in the secondary data center).
- The Load Balancer is configured to route traffic only to the UI servers in the currently active data center for user sessions. Note that the connections from the Load Balancer to the secondary data center are shown with dashes in the diagram to illustrate that they are not in use while the primary data center is the active data center.
Web Server Layer (Optional):
This architecture includes a set of web servers inserted to “front-end” the UI application servers. This type of architecture is ACCEPTABLE but NOT REQUIRED for use with IdentityIQ. IdentityIQ does not require web servers; however, Servlet Containers on the UI Application servers are necessary. Web servers are only required if Single Sign-On code is needed at the web-server layer or if IdentityIQ offloads SSL to the web-server layer. In most instances, SSL is offloaded to the load balancer. Most customers have chosen to not implement the web-server layer because it introduces unnecessary hops within the application’s architecture.
Sailpoint Production Deployment architecture With External Users Access:
In an organizations where internal & external both users need to access SailPoint IdentityIQ, an architecture using DMZ Reverse Proxies is a RECOMMENDED but NOT REQUIRED. IdentityIQ does not require DMZ Reverse Proxies, but it is required for the organizations to follow best security practices while deploying any tool. In most SailPoint IIQ deployments, SSL is carried all the way to the UI servers to secure traffic in the entire DMZ.
To Be Continued …