Standard deployment topology patterns overview

Authors: StevenBeard, TimFeeney, BreunReed, PaulEllis, ShubjitNaik
Build basis: CE/CLM 6.x (with some restrictions)

This page complements the Standard Topologies Overview by providing diagrams and description of the main patterns that can be used for specific reasons within a CE/CLM deployment topology. They include only the parts of the deployment topology needed to present the pattern and not all of the other nodes that can be deployed within the wider topology.

Rational Team Concert (RTC) clustering

• RTC clustering topology pattern for CE/CLM 6.0.5 and beyond:
  

This patterns shows just the CE/CLM nodes required to cluster RTC.

Please Note: The Jazz Authorization Server (JAS) is required for RTC clustering.

In the topic Setting up a Change and Configuration Management application clustered environment version 6.0.5 and later we provide specific guidance on setting-up a Distributed Cache Microservice (DCM) for clustered applications:

The microservice must be installed and run on a machine that is accessible by all nodes of the clustered application. By default, the microservice is installed on the Jazz Team Server (JTS) machine under the server/clustering/cache directory and is started as part of the JTS startup sequence (on demand, only when a clustered application asks for it).

Note: For optimal performance, the DCM should be moved to a dedicated machine. The size of this machine will depend on the number of users in your RTC cluster and their usage. DCM can be deployed on a machine as small as 2 core, 4gb RAM and 100GB disk, but you will need to monitor the system and increase its size based on your load. We found that a 4 core, 8gb ram, 200gb disk virtual machine handled 500 users (but it will vary based on what your users do with the system).

IBM HTTP Server (IHS) and Jazz Authorization Server (JAS) Clustering

• IHS and JAS clustering topology pattern for CE/CLM 6.0.2 and beyond:
  

An application delivery controller (ADC) is a computer network device in a datacenter, often part of an application delivery network, that helps perform common tasks, such as those done by web accelerators to remove load from the web servers themselves.

Many customer are already using an ADC e.g. F5 BIG-IP, CITRIX NetScaler, A10. We have quite a few customers using a combination of an ADC and an IHS Reverse Proxy. We have a few customers using multiple ADCs load balancing clustered IHS Reverse Proxies. Recently published best practice: Reverse Proxies and Load Balancers in CLM Deployment.

If you have an active Jazz deployment using Jazz Security Architecture (JSA) Single Sign-On, you can reduce the risk of outages by clustering a single Jazz Authorization Server with multiple replicas. If you only have a single JAS instance, then all authenticate requests will fail if that instance goes offline. If you have a JAS cluster, then login requests will succeed since they will automatically fall over to active JAS replicas.

Refer to the following Jazz Deployment article for additional guidance on configuring JAS Clustering: Setting up a cluster of Jazz Authorization Servers.

Modified Departmental patterns

• Modified Departmental topology pattern for CE/CLM 6.0.2 and beyond:
  

Multiple application servers of the same product

• Multiple application servers topology pattern for CE/CLM 6.x:
  

There has been clear guidance for several releases of CE/CLM on using multiple instances of the same application server:

• Planning for multiple Jazz server instances
• Multiple CCM Applications - A User Perspective

In CE/CLM 6.0.6 ifix003 we added Support for cross-server links with system and custom link types for RDNG.

Multiple database servers

• Multiple database servers topology pattern for CE/CLM 6.x:
  

Security (OIDC, SCIM, SAML)

Jazz Authorization Server as the OpenID Connect Provider

Starting with the Collaborative Lifecycle Management (CLM) Solution 6.0 software release, Jazz Security Architecture SSO is available as an authentication option. Based on OpenID Connect , authentication is NOT performed by the container hosting Jazz applications, but instead is delegated to a separate Jazz Authorization Server (JAS), which performs the role of an OpenID Connect provider (OP). Jazz Authorization Server is based on the IBM WebSphere Liberty profile.

For further Information on Jazz Security Architecture you can visit our jazz.net article Jazz Server Authentication Explained and our deployment wiki JAS Landing page

For instructions to configure CE/CLM to authenticate via JAS as OIDC provider please visit Configure OIDC Authentication for CE/CLM

• OIDC Topology pattern for CE/CLM 6.0 and beyond:
  

System for Cross-domain Identity Management (SCIM)

You can configure the Jazz Authorization Server (Liberty OpenID Connect Provider) to use the System for Cross-domain Identity Management (SCIM) for the WebSphere Application Server Liberty profile. SCIM is a standard for cloud-based identity management for single sign-on (SSO) in browsers. It is a RESTful protocol for identity account management operations. Starting with Collaborative Lifecycle Management (CLM) solution 6.0.5 software release, Jazz Authorization Server supports SCIM in the Liberty profile.

Restriction : When you configure your Jazz Authorization Server to use the System for Cross-domain Identity Management (SCIM), you cannot use the Electronic signatures features in Rational Team Concert.

For instructions to configure JAS with SCIM please visit Configure JAS for SCIM

• SCIM Topology pattern for CE/CLM 6.0.5 and beyond:
  

Third Party OIDC Provider

You can configure Jazz Authorization Server (Liberty OpenID Connect Provider) to further delegate the user authentication to your standard, corporate OpenID Connect provider using the Liberty Social Login feature. Using this method we can delegate authentication from JAS to another OIDC provider.

In this approach the user authentication is further delegated from JAS to another OIDC provider and this leads to redirections which some clients cannot do. Following are the limitations

• Authenticating through a Third Party OIDC provider works only for Browser based clients
• Thick Clients (Eclipse, Visual Studio) and Command line utilities can be configured to authenticate via JAS and hence JAS needs to be connected to the LDAP / Directory server that the Third Party OIDC provider works with.

For instructions to configure CE/CLM to authenticate via you in-house OIDC provider please visit the article Configure CE/CLM with Third Party OIDC Provider

• Third Party OIDC Provider Topology pattern for CE/CLM 6.0.6.1 and beyond:
  

SAML as Identity Provider

Starting in the Collaborative Lifecycle Management (CLM) version 6.0.1, Jazz Authorization Server supports Security Assertion Markup Language (SAML) web browser single sign-on (SSO) which enables web applications to delegate user authentication to a SAML identity provider instead of a configured user registry.

SAML is an OASIS open standard for representing and exchanging user identity, authentication, and attribute information. A SAML assertion is an XML formatted token that is used to transfer user identity and attribute information from the identity provider (IdP) of a user to a trusted service provider (SP) as part of completing an SSO request. For more information, see SAML web single sign-on.

In this approach the user authentication is further delegated from JAS to a SAML Identity Provider, this leads to redirections which some clients cannot do. Following are the limitations

• Authenticating through a SAML Identity Provider for CLM works only for Browser based clients
• Thick Clients (Eclipse, Visual Studio) and Command line utilities can be configured to authenticate via JAS and hence JAS needs to be connected to the LDAP / Directory server that is configured with the SAML Identity Provider.

For instructions to configure CE/CLM to Authenticate via SAML IDP please visit Configure CE/CLM with SAML IDP

• SAML topology pattern for CE/CLM 6.0.1 and beyond:
  

Related topics:

• Standard Topologies Overview
• Deployment planning
• Deployment planning and design

Additional contributors: