Ping Federate is used by one of our CA PPM clients to provide single sign-on capabilities for their Cloud and Internally based systems. To enable CA PPM to also utilise the Ping Federate infrastructure to improve the ease of access for the users of CA PPM, we were engaged to develop the capability for CA PPM to use Ping Federate for authentication therefore providing transparent sign on to CA PPM in line with the client’s other systems.
We worked with the client’s CA PPM and Ping Federate teams to develop the capability with the goals of:
- avoiding any architectural changes to CA PPM,
- minimising changes to CA PPM supplied files.
- ensuring the solution was robust and secure and,
- ensuring deep linking worked.
The diagram below shows at a high level the messages between the different components of the solution.
The solution comprised a Java based Servlet Filter that is installed into the CA PPM filter chain in Apache Tomcat to intercept the requests and verify whether a user is logged onto CA PPM and if not redirect the request to the Ping Federate Server for authentication. By installing the filter into the Apache Tomcat filter chain of CA PPM avoids having to create additional services to host the authentication filter and the corresponding configuration required to prevent direct access to the CA PPM services from any source other than the service hosting the authentication filter.
The filter library was installed into the CA PPM [INSTALL_DIR]/customlib directory and via entries in the [INSTALL_DIR]/webroot/WEB-INF/web.xml file only triggered for the app and nu URLs as follows:
</filter>
<!– end of filter defs –>
<!– Ping SSO Filter Def –>
<filter>
<description>Ping SSO Filter</description>
<display-name>Ping SSO Filter</display-name>
<filter-name>PingSSOFilter</filter-name>
<filter-class> com.pemari.pf.PingPPMFilter</filter-class>
<init-param>
<param-name>config</param-name>
<param-value>../config/sso.properties</param-value>
</init-param>
</filter>
<!– End of Ping SSO Filter Def –>
<!– filter mappings –>
<filter-mapping>
<filter-name>AddDefaultEncoding Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<!– This filter MUST come before the TenantSetupFilter DO NOT MOVE IT –>
<filter-mapping>
<filter-name>Charset Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<!– Ping SSO Filter mappings –>
<filter-mapping>
<filter-name>PingSSOFilter</filter-name>
<url-pattern>/app</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>PingSSOFilter</filter-name>
<url-pattern>/nu</url-pattern>
</filter-mapping>
<!– End of Ping SSO Filter mappings –>
<!– Have this filter as a first filter among the filters which use UtilityThreadLocal in the implementation–>
<filter-mapping>
<filter-name>TenantSetupFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Only enabling the filter for app and nu enables calls from the client connectors for Open Workbench and Microsoft Project as well as XOG to not route through the filter. For the New User Experience similar but not the same entries are placed in the [INSTALL_DIR]/webroot/cappm/WEB-INF/web.xml file. Once CA PPM SSO is enabled in CSA and the filter activated in it’s config file, Ping Federate is then used for Authentication and CA PPM’s built in security only used for Authorisation for the browser-based access to CA PPM.
This architecture is like that used by our CA PPM Single Sign-On product that uses Kerberos and/or NTLMv2 for Authentication and is a secure and workable solution for any SSO Authentication implementations with CA PPM.
The solution is now live with the 1000+ users of the system able to easily access CA PPM.