Integrate Clarity PPM with CA Single Sign-On (SSO)

CA Single Sign-On provides a centralized security management foundation that enables user authentication and controlled access to web applications and portals. CA Single Sign-On delivers advanced security management capabilities and enterprise-class site administration, enabling greater IT control and security.
CA Single Sign-On provides a centralized security management foundation that enables user authentication and controlled access to web applications and portals. CA Single Sign-On delivers advanced security management capabilities and enterprise-class site administration, enabling greater IT control and security.
CA Single Sign-On provides the following features:
  • Single Sign-On (SSO)
  • Strong Authentication Management
  • Centralized Policy-Based Authorization and Audit
  • Identity Federation
  • Enterprise Manageability
Organizations can manage single sign-on access to
Clarity PPM
by integrating with CA Single Sign-On. We highly recommend that you consult with CA PPM and CA Single Sign-On specialists from CA Services before planning or implementing this integration. Contact CA Services for assistance with all your CA product integrations.
The procedures on this page apply to
Clarity PPM
on-premise environments where the administrator can access CSA.
Clarity PPM
SaaS environments, CA can provide SSO for your users through the CA On Demand Portal. SaaS administrators can manage these user accounts in the portal.
CA Single Sign-On integrates with industry-leading directory services and user stores, eliminating redundant administration of user information. This integration simplifies administration and provides unique and comprehensive security capabilities. CA Single Sign-On fully leverages existing user directories, from leading LDAP directories and relational databases to mainframe security directories.
Real-time transactional security and integrated web services with CA Single Sign-On rules enable security policies that evaluate dynamic data from a variety of local or external sources. These sources include web services and databases in real time. Cost and complexity are reduced by eliminating advanced security logic from web applications and centralizing it within CA Single Sign-On policies.
Integration with CA Single Sign-On has been available for all
Clarity PPM
 components since the release of
Clarity PPM
 8.1.2. For further information about
Clarity PPM
 and CA Single Sign-On, refer to the
Clarity PPM
 Installation Guide, the Single Sign-On Policy Server installation documentation, and the Single Sign-On Web Agent installation documentation.
Integration Points and Functionality
The integration protects the
Clarity PPM
 application URIs with CA Single Sign-On by creating several realms, rules, and a policy. A rule identifies and controls access to specific resources that are included in the policy. A CA Single Sign-On policy binds rules and responses to users, groups and roles. The responses in a policy enable the solution to customize the delivery of content for each user.
Policies reside in the policy store, which is the data source that contains all of the CA Single Sign-On entitlement information. When a
Clarity PPM
 user tries to access the protected URI, that is, /niku/nu, /niku/services, or /niku/app URIs and is not already authenticated, CA Single Sign-On displays a login window and challenges the user for credentials. The user enters credentials and submits them, and is then authenticated against the CA Single Sign-On Policy server. CA Single Sign-On sets an HTTP Header containing the Single Sign-on token and redirects the request to the CA PPM Overview URL, so the CA PPM application is available to users to start their work.
The following steps provide an overview of how the
Clarity PPM
 and CA Single Sign-On integration works:
1. The user attempts to access a protected resource, which is the CA PPM web application.
2. The user is challenged for credentials and presents them to the Web Agent.
3. The user credentials are passed to the policy server.
4. The user is authenticated against the appropriate user store (such as LDAP or Active Directory).
5. The user receives access to the secured CA PPM web application.
Configure the SSO Token
  1. In CA PPM System Administration (CSA), navigate to your server
  2. Click on the
  3. Configure the security properties.
    image2017-3-21 14:7:58.png
  4. Configure the
    Single Sign-On
    image2017-3-21 14:8:35.png
    1. Token Name
      : Enter the same name that matches the token name in CA Single Sign-On. A custom response is added that sets an HTTP header (named cappmtoken in the examples presented in this document) with the user name from the LDAP Directory used for authentication.
    2. Token Type
      : The Token Type should be set to Header so that CA PPM checks the HTTP headers for the Single Sign-On token.
    3. Logout URL
      : Configure the logout URL with the location you would like the end user redirected to when they click the Logout link within CA PPM or when either their CA PPM or Single Sign-On sessions expire. 
    4. Authentication Error URL
      : Configure this URL with the location to redirect the user if any authentication error is encountered.
  5. Click
  6. Restart the CA PPM services.
Configure the Application Bind Address, Port, and Proxy
  1. In CA PPM System Administration (CSA), navigate to your server
  2. Click on the
  3. Configure the Apache Tomcat application server. 
  4. In the app instance settings, select the Use Single Sign-on option.
  5. If using mod_proxy (simple HTTP reverse proxy), configure the HTTP Port for the app instance to a non-privileged port. The 8080 port is used as an example. Configure the Bind Address field for the app instance (not the Tomcat Connector Bind Address) to the loopback address ( if the Apache HTTP server is on the same host.
  6. If setting a proxy from Microsoft IIS or Apache HTTP Server with the Apache Tomcat Connector, the Apache Tomcat Connector requires configuration of the Tomcat Connector Port and Tomcat Connector Bind Address for the CA PPM app instance. The Apache Tomcat Connector uses the ajp13 protocol. Configure the connection to the Tomcat Connector Port and not the HTTP Port.
    1. Set the Tomcat Connector Port to a non-privileged port such as 30001.
    2. Set the Tomcat Connector Bind Address to the loopback address ( if the Microsoft IIS or Apache HTTP server is on the same host.
  7. Click
Firewall Considerations for Multiple Host Configuration
If the Microsoft IIS or Apache HTTP server proxy into CA PPM resides on a separate physical host other than the CA PPM application instance, configure firewall rules (IPtables for Linux, Windows Firewall, or hardware firewall) so that only the HTTP proxy server IP address is permitted to reach the bind address and port chosen in the previous steps. Refer to your operating system documentation for information on firewall rule settings. 
Failure to secure Tomcat Application bind address leaves the CA PPM application open to attacks that bypass the CA Single Sign-On Web Agent protection. See Chapter 4, Securing SSO-enabled CA PPM Environments for more information on the repercussions of properly securing the Single Sign-On/CA PPM integrated environment.
LDAP Configuration in CA PPM for Schedulers
If you use CA Open Workbench or Microsoft Project with CA PPM, configure CA PPM authentication against the same LDAP directory that is used by CA Single Sign-On for authentication. After a period of inactivity in these scheduler applications, the CA PPM session in use will become invalid. When this occurs, Microsoft Project and Open Workbench prompt the user to authenticate before they can continue working. If LDAP is not configured as the authentication source for CA PPM, this authentication fails.
Refer to the CA PPM documentation for a detailed description of the steps for configuring CA PPM to authenticate with LDAP.  See Installing and Upgrading.
Configure the Policy Server
In this section, we refer to the following related terms as
  • uniform resource identifier (URI)
  • uniform resource locator (URL)
  • resource filter
  • path
  • realm
Clarity PPM
 14.x or older included the following paths:
  • /niku/app
  • /niku/nu
  • /niku/services
To support the 
New User Experience
Clarity PPM
 15.1 and newer added the following two paths:
  1. /pm
  2. /ppm/rest
As an administrator, protect these two new resource paths. Only protect the necessary URIs so that unnecessary calls are not made to the Single Sign-On Policy server. Customers who protect the full root may be required to unprotect additional URIs such as /reportservice. Protecting the full root is not recommended. 
Authentication Schemes
Note that in the examples below the Basic Auth scheme is used. This is just for simplicity of example and there is no requirement that the Basic Auth scheme should be used. In most environments the IWA (Integrated Windows Authentication) scheme is a popular choice. Selection of Authentication Scheme is left as a choice to the CA Single Sign-On implementation architect.
Single Sign-On Realms
Create realms in CA Single Sign-On for CA PPM:
The following image shows these realms in CA Single Sign-On:
image2017-3-21 14:59:6.png
REALM 1: CA PPM Legacy Application
CA PPM still makes use of the legacy URI /niku/app for some browser-based application functionality, especially for the Open Workbench and Microsoft Project scheduler tools. Configure Single Sign-On to protect every URI that does not match the following pattern:
All other URIs under /niku/app are protected. Scheduling tool (OWB or MSP) URIs are allowed to pass unprotected because they are not capable of handling an SSO authentication challenge.
Clarity PPM
directly authenticates access to these scheduler tools with a username and password.
You want to exclude schedulers but protect all other requests to /niku/app. Create a resource rule under the realm that uses the following regular expression:
REALM 2: CA PPM Application
The core functionality in CA PPM uses the URI /niku/nu and must be protected. 
REALM 3: CA PPM Services
For each realm, create a rule to protect /niku/services. This realm protects the resources used by the CA PPM user interface. These are primarily JSON requests from the web toolkit utilized by CA PPM.
REALM 4: CA PPM New User Experience
The new user experience in CA PPM uses the URI /pm and must be protected. This realm is required only if your implementation of the
New User Experience
 must also support SSO.
1. The resource must not have a forward slash (change /* to *).
2. In the Action section, include Delete, Head, and Trace in addition to Get, Post, and Put for the Web Agent actions.
The base URL /ppm/rest of REST APIs of CA PPM must to be protected if New UX will be accessed in SSO enabled CA PPM environment. . This realm is required only if New UX needs to support SSO.
In the Action section, include Delete, Head, and Trace in addition to Get, Post, and Put for the Web Agent actions.
REALM 6: CA PPM Advanced Reporting
This realm and rule are optional. The Advanced Reporting (Japsersoft) in CA PPM uses the URI /niku/reportserver. This must be un-protected. This is only necessary for customers who protect the full root, which is not recommended.
Realm Idle Timeouts
Set the idle session timeout to match the CA PPM application session timeout value. Both CA PPM and CA Single Sign-On default to 1 hour idle session timeout. The CA PPM session timeout is very important because it ensures that old inactive user sessions are removed from the Java heap. Set this for all of the realms that have been defined for CA PPM.
image2017-3-21 15:31:19.png
Create a Single Sign-On Policy
After you configure the realms and their rules, create a policy under the CA PPM Single Sign-On domain. Include the realms and rules as shown in the following image:
image2017-3-21 15:32:30.png
Create Single Sign-On Response
To provide a consistent HTTP header token for CA PPM to use for SSO, create a response that maps the user name LDAP Directory attribute to the new HTTP header cappmtoken. The Single Sign-On built-in HTTP header for the user name is SM_USER, but when Microsoft IIS is configured with the Apache Tomcat Connector, all of the HTTP header variables have the underscore characters turned into dashes, making it SM-USER. It is easier and more consistent to make a token that does not contain an underscore character.
The token name must match the value that has been configured for SSO in CA PPM.
Follow these steps
  1. Click Create to create a new response named cappmtoken.
    image2017-3-21 15:34:17.png
  2. Create a new attribute within the response, with the following characteristics: Attribute Kind: User Attribute Variable Name: cappmtoken Attribute Name: name of the LDAP user_name attribute
    The attribute name for the user name field differs between LDAP implementations and configurations: 
    • uid
      : Use this value for CA Directory or other LDAP RFC compliant directories.
    • sAMAccountName
      : Use this value for Microsoft Active Directory. 
    • mail
      : Use this LDAP value if you configure CA PPM to use the email address as the login ID.
      Illustrations of the response properties and the response attribute details appear below.
       image2017-3-21 15:35:27.png image2017-3-21 15:36:34.png
  3. Associate rules and responses in the CA PPM Policy. Map the CA PPMToken response (created in step 2) to all of the Single Sign-On rules that you created earlier as shown in the following image:
    image2017-3-21 15:38:44.png
Agent Properties, LogoffUri, IgnoreExt, and IgnoreUrl
Set the CA SSO LogoffUri value to the CA PPM logout URI. When a
Clarity PPM
 user logs out, the SSO session is also invalidated.
  1. Open the CA SSO Agent Configuration settings.
  2. Add or Modify the LogoffUri in your Agent Configuration Object (ACO) 
    1. Parameter Name = logoffUri
    2. Parameter 1 = /niku/nu#action:security.logoutAction
    3. Parameter 2 = /ppm/rest/v1/auth/logout
    4. Note: The Parameter 2 is needed when New UX will be accessed in SSO enabled CA PPM environment.
    image2017-3-21 15:45:59.png
  3. The following changes are needed when the
    New User Experience
     is accessed in an SSO-enabled CA PPM environment. Add or modify the IgnoreExt and IgnoreUrl in your Agent Configuration Object (ACO). Add the
    Clarity PPM
    New User Experience
     font file extensions to the list of ignored extensions.
    1. Parameter Name = IgnoreExt 
    2. Add Values = .woff,.svg,.ttf,.eot 
      Separate the extensions with commas.
    3. Parameter Name = IgnoreUrl 
    4. Add Value = /pm/js/core/layout/logout.html
      The above parameter values are needed when New UX will be accessed in SSO enabled CA PPM environment.
  4. Add or modify the BadUrlChars and BadQueryChars in your Agent Configuration Object (ACO). The rest API URLs consist of sensitive chars such as single quote. To avoid API failure with Forbidden (403), check following properties and change the value accordingly. 
    • BadUrlChars: If this property exists, check the value and remove single quote if it exists in it. If it does not exist, you may need to add/enable this property but don’t give any value.
    • BadQueryChars: If this property exists, check the value and remove single quote if it exists in it. If it does not exist, you may need to add/enable this property but don’t give any value.
      image2017-3-21 15:50:44.png
Securing CA PPM Environments Where SSO is Enabled
In order for Single Sign-On SSO to properly protect the CA PPM application server instances, ensure that no users are able to bypass the Single Sign-On Web agent layer. The below diagram indicates the potential for attack in a vulnerable SSO-enabled CA PPM environment:
image2017-3-21 15:52:15.png
A typical representation of an SSO-enabled CA PPM environment utilizing Single Sign-On Secure Proxy server, great care must be taken to ensure that only the Single Sign-On Secure Proxy server can connect to the CA PPM application servers. If the CA PPM application ports can be reached directly over the network by anyone (bypassing Single Sign-On), a malicious user may connect to the CA PPM application port, supply their own HTTP header value and successfully log into CA PPM as any user.
In the following possible solution, the Single Sign-On web agent is instead running in an Apache HTTP server that is on the same host as the CA PPM application. The server level firewall (Windows Firewall or Linux Iptables firewall) is configured to only allow an end-user to connect to TCP port 80, which is bound to the public IP address by the Apache HTTP Server. The CA PPM application is bound to the loopback address (Application bind address is configured via the CA PPM CSA) and a non-priviledged port (TCP/8080). The loopback address is only reachable by processes running locally on the server. Users on the network can no longer connect to the CA PPM application directly without first being authenticated/authorized by Single Sign-On.
A secure 
Clarity PPM
 environment with SSO appears in the following diagram:
image2017-3-21 15:54:33.png
We strongly recommend that you test after configuring CA PPM for SSO. Determine whether the SSO configuration can be circumvented. Attempt to directly bypass the Single Sign-On web agent and connect directly to the ports bound by the CA PPM Application. If these attempts to bypass Single Sign-On enforcement are successful, work with your System Administrator, Network Administrator and CA PPM Administrator to reconfigure the environment so that it is secure.
Proxy from a Typical Apache 2.x HTTP Server
In order for Single Sign-On SSO to completely protect the CA PPM application server instances, CA PPM itself must prevent any users from bypassing the Single Sign-On Web agent. A typical configuration for Single Sign-On with CA PPM would be to have the Single Sign-On Web Agent running in an Apache HTTP server on the same server that is running the CA PPM application instance. In order to prevent users from reaching the CA PPM instance directly, bypassing the SSO web agent, CA PPM should be bound to the loopback address ( on a non-privileged port (such as 8080). To do this, go to the Application settings in the CSA (CA PPM System Administrator) and adjust the "app" instance HTTP Port and Bind Address entries.
The Apache HTTP Server should be bound to a public IP address and a privileged port (80 or 443 if SSL is used). Apache should also be configured either as a reverse proxy with mod_proxy or with the Apache Tomcat Connector to communicate with the CA PPM application instance. The typical configuration, documented below, uses the mod_proxy method. In the majority of configurations, mod_proxy is sufficient. The only functionality provided by the Apache Tomcat Connector that mod_proxy does not offer is software load balancing. The configuration of the Apache Tomcat Connector for Apache HTTP Server is not provided in this document, but can be found here:
The following diagram illustrates a typical CA PPM integration with CA SSO on an Apache server:
CA PPM with SSO.
The following configuration can be used in an Apache 2.2.x or Apache 2.4.x web server to handle both the reverse proxy and the initial redirects required to land the end user on the CA PPM Overview page:
# Initial CA PPM redirects for SSO # # NOTE: be sure to uncomment LoadLibrary lines for the following modules: # # proxy_module # proxy_http_module # rewrite_module # RewriteEngine On RewriteRule ^$ http://%{SERVER_NAME}/niku/nu [R] RewriteRule ^/$ http://%{SERVER_NAME}/niku/nu [R] ProxyPass / ProxyPassReverse /
Proxy from Microsoft IIS
Microsoft IIS has an additional configuration requirement that is not found in Apache 2.x, because there is no built-in Proxy functionality in IIS. Instead, the Apache/Tomcat Connector must be used.
When used with Microsoft IIS, the Apache Tomcat Connector automatically converts the underscore character in HTTP Headers to the dash character. Any SSO Header Token value that contains an underscore character will need to have the underscore replaced with a dash. In Chapters 2 and 3, the HTTP header token was set to cappmtoken to prevent this issue from occurring.
More information can be found on integrating the Apache Tomcat Connector with IIS at: Apache Tomcat Connector IIS How-to.
The only major CA PPM configuration difference from the mod_proxy proxy method, presented in the previous section, is that the Tomcat Connector Bind Address and Tomcat Connector Port in the CSA Application settings must be set to the loopback address ( and a non-privileged port (such as 30001) as described above in the reverse proxy Apache example. In addition, for security purposes, the HTTP Port and Bind Address values should still be set to a non-privileged port (such as 8080) and the loopback address ( respectively, to prevent end-users from bypassing the Web Agent in IIS. The Apache Tomcat Connector will communicate directly with the Tomcat Connector Port in the CA PPM Application instance using the ajp13 protocol (not HTTP).
The following diagram illustrates a typical CA PPM integration with CA SSO on a Microsoft IIS server:
image2017-3-24 7:41:57.png
For this option, install the Apache Tomcat Connector in Microsoft IIS.
Follow these steps
  1. Download the ISAPI Redirector (isapi_redirect.dll) file.The Apache Tomcat Connector for IIS has been implemented as an ISAPI filter DLL. This DLL can be downloaded from:
    The latest version of the DLL, at the creation date of this document, is 1.2.37. The DLL needed for IIS can be downloaded from the win32/i386/x64 "binaries" section and is named isapi_redirect.dll. For 64-bit Windows 2008 / 2012, use the x86-64 binary (
  2. Place isapi_redirect.dll in the Tomcat bin directory. The Isapi Redirector DLL files sometimes include their version numbers when downloaded. If the files contain version numbers, you must rename the file from "isapi_redirect-1.2.XX.dll" to "isapi_redirect.dll" and place it in the "bin" directory of the Apache Tomcat installation (i.e. c:\ca\cappm\apache-tomcat-7.0.42\bin\isapi_redirect.dll).
  3. Rename the downloaded DLL to isapi_redirect.dll.
  4. Create the & files. These files are read by the Isapi Redirector when IIS is started and these files provide configuration information necessary for the Tomcat Connector to reach the Tomcat application server. The file describes the hosts and ports used by the workers (Tomcat processes). The information in this file should match the bind address and port information from your CA PPM Tomcat configuration. Place this file into the "conf" directory under your Tomcat installation (c:\ca\cappm\apache-tomcat-7.0.42\conf\ 
    # Define 1 real worker using ajp13 worker.list=worker1 # Set properties for worker1 (ajp13) worker.worker1.type=ajp13 worker.worker1.port=30001
    The file maps the URI patterns to workers. This file will contain one pattern, /*. This file should also be placed into the "conf" directory under your Tomcat installation (c:\ca\cappm\apache-tomcat-7.0.42\conf\
    # pattern for CA PPM /*=worker1
  5. Configure the ISAPI Redirector. To integrate the ISAPI redirector with IIS, several keys and values must be added to the Windows registry.
    1. Using "regedit" and being very careful to match the spelling exactly, create a new registry key named HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\1.0
    2. Add a String value with the name extension_uri with a value of /jakarta/isapi_redirect.dll
    3. Add a String value with the name log_file and a value pointing to the location you wish to have your connector logfile (for example: c:\ca\cappm\apache-tomcat-7.0.42\logs\isapi_redirect.log)
    4. Add a String value with the name log_level and a value for your log level (valid values are debug, info, error or emerg). When finished with initial testing, be sure to set the level back to error to limit the amount of information logged.
    5. Add a String value with the name worker_file and a value that is the full path to your file (for example c:\ca\cappm\apache-tomcat-7.0.42\conf\
    6. Add a String value with the name worker_mount_file and a value that is the full path to your file (for example c:\ca\cappm\apache-tomcat-7.0.42\conf\
  6. IIS Web Site Configuration (IIS v7/v7.5 only)
    1. Ensure that the IsapiFilterModule and IsapiModule are installed in IIS. These will not typically be installed by default. These modules can be installed using the Internet Information Services Manager.image2017-3-24 7:45:26.png
    2. Add the ISAPI Redirector to the list of allowed “ISAPI and CGI Restrictions” at the top server level in the IIS Manager.
      1. Select the machine name in the Connections pane in the IIS Manager.
      2. Under the “IIS” Section in the main window body, double-click the icon labeled “ISAPI and CGI Restrictions”
      3. Click Add in the Actions pane and click the “…” button. Navigate to the location of the file “isapi_redirect.dll” that was configured earlier and select it. 
      4. Check the box marked Allow extension path to execute. 
      5. Click OK to accept the values.
        image2017-3-24 7:48:1.png
      6. Verify that the ISAPI redirector is now in the list of allowed ISAPI and CGI Restrictions.
        image2017-3-24 7:49:27.png
    3. Add the ISAPI Redirector as an ISAPI Filter to the IIS web site (Default Web Site is shown in the example) by following these steps:
      1. Select the web site in the left navigation.
      2. Double-click the
        ISAPI Filters
        icon in the window.
      3. Click
        in the Actions pane. The Filter Name must be jakarta and the Executable value should be the full path to the isapi_redirector.dll file.
        image2017-3-24 7:50:49.png
    4. Using the IIS Manager, right-click on your web site and select Add Virtual Directory. The name of the virtual directory must be jakarta. Its physical path should be the directory where you placed the file isapi_redirect.dll.
      image2017-3-24 7:51:38.png
    5. Grant execute permissions to the ISAPI-dll Handler Mapping for the new directory. 
      1. Select the Jakarta virtual directory in the left navigation pane and then double-click the“Handler Mappings icon in the main window.
      2. Right-click the disabled ISAPI-dll entry and select Edit Feature Permissions.
        image2017-3-24 7:52:51.png
      3. In the Edit Feature Permissions dialog, check Execute and click OK.
    6. Restart IIS Manager and test the ISAPI Redirector by opening the IIS website URL with a browser followed by /niku/nu. For example: http://localhost/niku/nu
    7. Configure the root context browser re-direct in IIS. Create a default HTML document with META-REFRESH directive. IIS redirects SSO users to the CA PPM overview landing page when they enter the web server at the root context.
      1. Create a document in the IIS web document root (typically c:\inetpub\wwwroot) named default.htm.
      2. Enter the following content into that file:
        <html> <head> <meta http-equiv="refresh" content="0;url=/niku/nu"/> </head> <body/> </html>
Proxy Timeouts
In order for CA PPM to properly operate, idle TCP timeouts must be set correctly throughout the architecture at points that serve as reverse proxies. This includes hardware load balancers (F5 Big IP, Cisco Content Switch, etc.), Single Sign-On Secure Proxy Server, Apache HTTP Server or Microsoft IIS.
We recommend setting the idle TCP timeout to 15 minutes. Several actions in CA PPM, particularly Reports executed in immediate mode from a browser, can run for up to 10 minutes before CA PPM responds back to the user warning them that the report is taking too long to execute. During this 10 minute period, the TCP connection from the browser to CA PPM is essentially idle. Any timeouts imposed by a proxy device between the end user and CA PPM can result in a misleading error to the end user and do not accurately reflect an error experienced in the CA PPM Application.
Apache HTTP Server
  • mod_proxy: ProxyTimeout 900
    In the Apache configuration file, include the following directive to extend the Proxy timeout from the default to 900 seconds when using mod_proxy. By default under Apache HTTP Server, the ProxyTimeout value automatically assumes the value of the Timeout setting (defaults to 300 seconds). 
  • mod_jk
    When using mod_jk (Tomcat connector), the default socket_timeout value is 0 and thus timeout is disabled. No configuration for timeout is necessary.
Microsoft IIS
Under an IIS website, the “Advanced Settings” for will allow the “Connection time-out” to be changed from the default of 120 seconds to 900 seconds for CA PPM.
image2017-3-24 7:55:50.png
F5 Big IP
Under the F5 TCP Profile, the “Idle Timeout” value should be set to 900 seconds.
image2017-3-24 7:56:49.png
Single Sign-On Secure Proxy Server
Under CA Single Sign-On Secure Proxy Server, the timeout can be adjusted as part of the Agent settings used by the