Authentication Managers are used to integrate use repositories (identity management) and signon methods (access management).
When more than one authentication manager is configured,
one of them has to be made the
default
and will serve as primary authentication system, whereas
all others are secondary authentication systems. The
primary authentication system is responsible for the
access management and any secondary authentication
systems define extending user repositories for storing
additional data. See Portal Property Paths
(Section 8.1, “Portal”)
to learn how to access each Authentication Manager's
properties separately.
The configuration consists of two parts
Authentication Descriptors that defines how users are authenticated and how parameters from the user repositories are mapped onto user parameters in the portal.
Anonymous Parameters to defined the user profile for users that are not logged in.
See Section 8.3, “authentication-section” for details on configuration of the authentication managers.
This overview will describe how frontend editing will work with CAS authentication. An authenticated portal user with the appropriate permissions will be able to request resources from the Gentics Content.Node Server. Those requests will be dispatched using the “GCNProxyServlet” (Section 2). This servlet enables the client to request data via ajax from the Gentics Content.Node server. Otherwise client browsers would block those requests due to cross site ajax limitations. Additionally the “GCNProxyServlet” (Section 2) modifies the request so that the response data can be used within the context of your portal application.
CAS will also be used to authenticate the portal user against Content.Node. CAS Proxy authentication will be used in order to overcome the limitations of the separation between backend and frontend services. The “GCNCasProxyAuthenticationServletFilter” (Section 3) will add the needed Content.Node authentication information to the passed request. The filter itself will dispatch a CAS proxy request to Gentics Content.Node in order to collect the needed authentication information. Those information will be added to the filtered request.
You'll have to configure your portal and Gentics Content.Node server in order to enable Gentics Content.Node authentication for your portal implementation.
Components that have to be configured:
The CAS server must be configured in order to work with cas proxy authentication. Please refer to the cas documentation. (e.g: A HttpBasedServiceCredentialsToPrincipalResolver credential resolver bean is mandatory). The CAS server must be able to communicate with the Portal server over HTTPS. You may need to import the used Portal SSL certificate within the keystore that is used for the CAS server.
The Gentics Content.Node server must be able to access the CAS server via HTTPS. Importing the CAS ssl certificate in the JDK keystore is needed in order to avoid problems with ssl certificates authentication. The CAS server must be able to communicate with the Gentics Content.Node backend server. This is needed because the CAS filters will try to validate incoming proxy tickets against the CAS server. It's also mandatory to configure the CAS SSO acording to provided guides. This includes filter configuration on the Gentics Content.Node backend server. Please refer to the provided Gentics Content.Node documentation.
The Portal server must be able to access the Gentics Content.Node server via HTTP and it must be able to communicate with the CAS Server over HTTPS. You may have to install the CAS server SSL certificate in the keystore of the JDK as well.
Note: You may have to add the Portal SSL certificate when you deploy the CAS Webapp on the same system and both share one certificate.
The CAS filters and the GCN authentication filters have to be configured. A example configuration can be found here: “Example configuration” (Section 3.4)
Please note that the “GCNProxyServlet” (Section 2) is now a part of Portal.Node. The package path was changed to com.gentics.portalnode.proxy.GCNProxyServlet
The configuration of the “GCNCasProxyAuthenticationServletFilter” (Section 3) can be found here.
Note: You'll have to change the DispatchFilter ignore pattern when you want to place the GCNProxyServlet within the Gentics Portal.Node Webapp configuration.
Please configure your Gentics Content.Node Server according to the Gentics Content.Node documentation. An example configuration witch is CAS proxy enabled could look like this.
Example 3.1. Syntax Example Gentics Content.Node Configuration
<!-- =============== CAS SSO Filter Start =============== --> <!-- Filter parameter shared by some filters --> <context-param> <param-name>casServerLoginUrl</param-name> <param-value>https://mycas/cas-server/login</param-value> </context-param> <context-param> <param-name>casServerUrlPrefix</param-name> <param-value>https://mycas/cas-server</param-value> </context-param> <context-param> <param-name>serverName</param-name> <param-value>http://cms.my-gcn-server</param-value> </context-param> <!-- The authentication filter will check, whether CAS Authentication is necessary and will redirect to the CAS Server --> <filter> <filter-name>CAS Authentication Filter</filter-name> <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class> <init-param> <param-name>gateway</param-name> <param-value>false</param-value> </init-param> </filter> <filter-mapping> <filter-name>CAS Authentication Filter</filter-name> <url-pattern>/rest/auth/login</url-pattern> </filter-mapping> <!-- The Ticket Validation Filter will validate the Ticket (found in the query as additional parameter) against the CAS Server and will do a redirect to the service without the ticket --> <filter> <filter-name>CAS Ticket Validation Filter</filter-name> <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class> <init-param> <param-name>acceptAnyProxy</param-name> <param-value>true</param-value> </init-param> </filter> <filter-mapping> <filter-name>CAS Ticket Validation Filter</filter-name> <url-pattern>/rest/auth/login</url-pattern> </filter-mapping> <!-- The Assertion Thread Local Filter makes the assertion available as ThreadLocal (the CASIntegrationFilter depends on it) --> <filter> <filter-name>CAS Assertion Thread Local Filter</filter-name> <filter-class>org.jasig.cas.client.util.AssertionThreadLocalFilter</filter-class> </filter> <filter-mapping> <filter-name>CAS Assertion Thread Local Filter</filter-name> <url-pattern>/rest/auth/login</url-pattern> </filter-mapping> <!-- The CASIntegrationFilter reads the assertion, matches it against the User-DB (or creates a new user). And performs the login. --> <filter> <filter-name>CAS GCN Integration Filter</filter-name> <filter-class>com.gentics.contentnode.auth.filter.CASIntegrationFilter</filter-class> <init-param> <param-name>initGroups</param-name> <param-value>[4, 6]</param-value> <!-- expression that returns the ids of the initial groups --> </init-param> </filter> <filter-mapping> <filter-name>CAS GCN Integration Filter</filter-name> <url-pattern>/rest/auth/login</url-pattern> </filter-mapping> <!-- =============== CAS SSO Filter End =============== -->
For more information about cas proxy authentication please take a look at the following walkthrough: https://wiki.jasig.org/display/CAS/Proxy+CAS+Walkthrough