Integrate
Clarity
with CA Single Sign-On (SSO)

ccppmop1591
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
Classic PPM
by integrating with CA Single Sign-On. We highly recommend that you consult with
Clarity
and CA Single Sign-On specialists from Broadcom Service partners before planning or implementing this integration. Contact Broadcom Service partners for assistance with all your CA product integrations.
The procedures on this page apply to
Classic PPM
on-premise environments where the administrator can access CSA.
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
Classic PPM
components since the release of
Classic PPM
8.1.2. For further information about
Classic PPM
and CA Single Sign-On, refer to the
Classic PPM
Installation Guide, the Single Sign-On Policy Server installation documentation, and the Single Sign-On Web Agent installation documentation.
2
Integration Points and Functionality
The integration protects the
Classic 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
Classic 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
Clarity
Overview URL, so the
Clarity
application is available to users to start their work.
The following steps provide an overview of how the
Classic PPM
and CA Single Sign-On integration works:
1. The user attempts to access a protected resource, which is the
Clarity
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
Clarity
web application.
Configure the SSO Token
  1. In
    Clarity
    System Administration (CSA), navigate to your server
    Properties
    page.
  2. Click on the
    Security
    link.
  3. Configure the security properties.
    image2017-3-21 14:7:58.png
  4. Configure the
    Single Sign-On
    options:
    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
      Clarity
      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
      Clarity
      or when either their
      Clarity
      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
    Save
    .
  6. Restart the
    Clarity
    services.
Configure the Application Bind Address, Port, and Proxy
  1. In
    Clarity
    System Administration (CSA), navigate to your server
    Properties
    page.
  2. Click on the
    Application
    link.
  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 (127.0.0.1) 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
    Clarity
    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 (127.0.0.1) if the Microsoft IIS or Apache HTTP server is on the same host.
  7. Click
    Save
    .
Firewall Considerations for Multiple Host Configuration
If the Microsoft IIS or Apache HTTP server proxy into
Clarity
resides on a separate physical host other than the
Clarity
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
Clarity
application open to attacks that bypass the CA Single Sign-On Web Agent protection. See Chapter 4, Securing SSO-enabled
Clarity
Environments for more information on the repercussions of properly securing the Single Sign-On/
Clarity
integrated environment.
LDAP Configuration in
Clarity
for Schedulers
If you use CA Open Workbench or Microsoft Project with
Clarity
, configure
Clarity
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
Clarity
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
Clarity
, this authentication fails.
Refer to the
Clarity
documentation for a detailed description of the steps for configuring
Clarity
to authenticate with LDAP.  See Installing and Upgrading.
Configure the Policy Server
In this section, we refer to the following related terms as
paths
or
realms
.
  • uniform resource identifier (URI)
  • uniform resource locator (URL)
  • resource filter
  • path
  • realm
Classic PPM
14.x or older included the following paths:
  • /niku/app
  • /niku/nu
  • /niku/services
To support
Clarity
,
Classic 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
Clarity
:
5
5
The following image shows these realms in CA Single Sign-On:
image2017-3-21 14:59:6.png
REALM 1:
Clarity
Legacy Application
Clarity
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:
*/niku/app*action=sch*
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.
Classic 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:
.*action=(([^s])|(.[^c])|(..[^h])).*
realm2.png
REALM 2:
Clarity
Application
The core functionality in
Clarity
uses the URI /niku/nu and must be protected.
realm3.png
REALM 3:
Clarity
Services
For each realm, create a rule to protect /niku/services. This realm protects the resources used by the
Clarity
user interface. These are primarily JSON requests from the web toolkit utilized by
Clarity
.
realm1.png
REALM 4:
Clarity
Clarity
uses the URI /pm and must be protected. This realm is required only if your implementation of
Clarity
must also support SSO.
realm4.png
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.
REALM 5:
Clarity
REST API
The base URL /ppm/rest of REST APIs of
Clarity
must to be protected if
Clarity
will be accessed in SSO enabled
Clarity
environment. . This realm is required only if
Clarity
needs to support SSO.
realm5.png
In the Action section, include Delete, Head, and Trace in addition to Get, Post, and Put for the Web Agent actions.
REALM 6:
Clarity
Advanced Reporting
This realm and rule are optional. The Advanced Reporting (Japsersoft) in
Clarity
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.
realm6.png
Realm Idle Timeouts
Set the idle session timeout to match the
Clarity
application session timeout value. Both
Clarity
and CA Single Sign-On default to 1 hour idle session timeout. The
Clarity
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
Clarity
.
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
Clarity
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
Clarity
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
Clarity
.
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
      Clarity
      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
    Clarity
    Policy. Map the
    Clarity
    Token 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
Clarity
logout URI. When a
Classic 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
      Clarity
      will be accessed in SSO enabled
      Clarity
      environment.
    image2017-3-21 15:45:59.png
  3. The following changes are needed when the
    Clarity
    is accessed in an SSO-enabled
    Clarity
    environment. Add or modify the IgnoreExt and IgnoreUrl in your Agent Configuration Object (ACO). Add the
    Classic PPM
    Clarity
    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
      Clarity
      will be accessed in SSO enabled
      Clarity
      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
Clarity
Environments Where SSO is Enabled
In order for Single Sign-On SSO to properly protect the
Clarity
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
Clarity
environment:
image2017-3-21 15:52:15.png
A typical representation of an SSO-enabled
Clarity
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
Clarity
application servers. If the
Clarity
application ports can be reached directly over the network by anyone (bypassing Single Sign-On), a malicious user may connect to the
Clarity
application port, supply their own HTTP header value and successfully log into
Clarity
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
Clarity
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
Clarity
application is bound to the 127.0.0.1 loopback address (Application bind address is configured via the
Clarity
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
Clarity
application directly without first being authenticated/authorized by Single Sign-On.
A secure
Classic PPM
environment with SSO appears in the following diagram:
image2017-3-21 15:54:33.png
We strongly recommend that you test after configuring
Clarity
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
Clarity
Application. If these attempts to bypass Single Sign-On enforcement are successful, work with your System Administrator, Network Administrator and
Clarity
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
Clarity
application server instances,
Clarity
itself must prevent any users from bypassing the Single Sign-On Web agent. A typical configuration for Single Sign-On with
Clarity
would be to have the Single Sign-On Web Agent running in an Apache HTTP server on the same server that is running the
Clarity
application instance. In order to prevent users from reaching the
Clarity
instance directly, bypassing the SSO web agent,
Clarity
should be bound to the loopback address (127.0.0.1) on a non-privileged port (such as 8080). To do this, go to the Application settings in the CSA (
Clarity
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
Clarity
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:
http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html
The following diagram illustrates a typical
Clarity
integration with CA SSO on an Apache server:
Clarity 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
Clarity
Overview page:
# Initial
Clarity
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 / http://127.0.0.1:8080/ ProxyPassReverse / http://127.0.0.1:8080/
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
Clarity
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 (127.0.0.1) 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 (127.0.0.1) 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
Clarity
Application instance using the ajp13 protocol (not HTTP).
The following diagram illustrates a typical
Clarity
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: http://tomcat.apache.org/download-connectors.cgi
    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 (tomcat-connectors-1.2.37-windows-x86_64-iis.zip)
  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 workers.properties & uriworkermap.properties 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 workers.properties 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
    Clarity
    Tomcat configuration. Place this file into the "conf" directory under your Tomcat installation (c:\ca\cappm\apache-tomcat-7.0.42\conf\workers.properties).
    # Define 1 real worker using ajp13 worker.list=worker1 # Set properties for worker1 (ajp13) worker.worker1.type=ajp13 worker.worker1.host=127.0.0.1 worker.worker1.port=30001
    The uriworkermap.properties 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\uriworkermap.properties).
    # pattern for
    Clarity
    /*=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 workers.properties file (for example c:\ca\cappm\apache-tomcat-7.0.42\conf\workers.properties)
    6. Add a String value with the name worker_mount_file and a value that is the full path to your uriworkermap.properties file (for example c:\ca\cappm\apache-tomcat-7.0.42\conf\uriworkermap.properties)
  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
        Add
        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
      Clarity
      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
Clarity
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
Clarity
, particularly Reports executed in immediate mode from a browser, can run for up to 10 minutes before
Clarity
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
Clarity
is essentially idle. Any timeouts imposed by a proxy device between the end user and
Clarity
can result in a misleading error to the end user and do not accurately reflect an error experienced in the
Clarity
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
Clarity
.
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