Skip to main content
Version: 8.2411.x.x RR

Configuring user authentication

To only allow authenticated users to access protected resources, the IdentityCreationFilter needs to be mapped in front of the servlet that accesses these sensitive resources. For validation of user credentials, the already configured EsAuthConnector is used.

The following configuration steps are needed:

  • Configure an IdentityCreationFilter to reference an authentication servlet or authentication service connector servlet, and assign an SSO (single sign-on) domain. Specify a login rendering application that provides customized login pages for this SSO domain. As nevisAuth may need to add the reverse proxy's identification (entry ID) to the signed authentication data (SecToken), an (optionally instance-specific) entry ID needs to be specified. This ID may be used by content providers to check that a request was issued using a specific entry point into the Nevis environment.
  • The IdentityCreationFilter is referencing a servlet that will be used for rendering login pages. This login servlet may be an HttpConnectorServlet accessing a content provider that uses the GUI description provided by the authentication service to render login forms, error messages, and more. We will use nevisProxy's (customizable, plug&play) built-in login renderer servlet here, which has the advantage of not being forced to send any inauthentic requests to the Intranet. For more information, see the chapter LoginRendererServlet. As nevisAuth is returning a signed security token containing the authenticated user data, nevisProxy needs to verify the token to make sure the correct authentication service was used. The public key of the nevisAuth's signer certificate needs to be installed locally. If the fallback nevisAuth instance uses another signer key, both certificates need to be added. Refer to the nevisAuth Reference Guide, chapter Distributing the Token Signer's Public Key about key handling.
  • Map the configured IdentityCreationFilter on all reverse proxy resources that require the same authentication infrastructure and constitute a group of resources that are accessible with one single login.
  • Restart nevisProxy and test the protected resources with a browser. You need to get a login panel. Login using credentials required by the configured authentication infrastructure. After login, you need to be able to access the content providers again.

These configuration steps lead to the following entries in the web.xml file:

<context-param>
 <param-name>SectokenVerifyCert</param-name>
 <param-value>
          /var/spool/keybox/nevis/auth_truststore/certificate1.pem
          /var/spool/keybox/nevis/auth_truststore/certificate2.pem
 </param-value>
</context-param>
 
<filter>
 <filter-name>Authentication</filter-name>
 <filter-class>ch::nevis::isiweb4::filter::auth::IdentityCreationFilter</filter-class>
  
 <init-param>
          <param-name>AuthenticationServlet</param-name>
          <param-value>EsAuthConnector</param-value>
 </init-param>
 <init-param>
          <param-name>LoginRendererServlet</param-name>
          <param-value>BuiltinLoginRenderer</param-value>
 </init-param>
 <init-param>
          <param-name>Realm</param-name>
          <param-value>SSOdefault</param-value>
 </init-param>
 <init-param>
          <param-name>EntryPointID</param-name>
          <param-value>www.company.com/instance1</param-value>
 </init-param>
</filter>
 
<servlet>
 <servlet-name>BuiltinLoginRenderer</servlet-name>
 <servlet-class>ch::nevis::isiweb4::servlet::rendering::LoginRendererServlet</servlet-class>
</servlet>
 
<filter-mapping>
 <filter-name>Authentication</filter-name>
 <url-pattern>/appl1/weak/*</url-pattern>
</filter-mapping>

<filter-mapping>
 <filter-name>Authentication</filter-name>
 <url-pattern>/appl2/*</url-pattern>
</filter-mapping>

<filter-mapping>
 <filter-name>Authentication</filter-name>
 <url-pattern>/appl3/*</url-pattern>
</filter-mapping>

If the user is now accessing e.g. /appl1, the content provider may want to verify that the user was properly authenticated by the reverse proxy. This is done by delegating the signed authentication data - the nevisAuth's SecToken - from nevisProxy to the content provider, which in turn needs to validate the token (using the signer's public key) before granting access.

Therefore the delegation filter needs to be added to the configuration. The SecToken will be delegated as an HTTP header with the name isiwebsectoken when using the following configuration:

<filter>
 <filter-name>DelegationFilter</filter-name>
 <filter-class>ch::nevis::isiweb4::filter::delegation::DelegationFilter</filter-class>
 <init-param>
          <param-name>Delegate</param-name>
          <param-value>AUTH:user.auth.SecToken:isiwebsectoken</param-value>
 </init-param>
</filter>

As this is a common usage scenario, the above setup can be replaced by just enabling SecToken propagation in the authentication module, see the DelegateSecToken parameter if the IdentityCreationFilter.

The SecToken is very security sensitive and should only be sent to trusted services over a secure channel.

A J2EE servlet container plug-in is available, which transparently performs the required security checks and associates the local container session with the global SSO session, managed by nevisProxy.

Session terminations are generally triggered by a user logout or a time-out in nevisProxy. However, nevisAuth can also terminate sessions. A session termination caused by nevisAuth must be communicated to nevisProxy. To this end, nevisProxy uses a polling mechanism to fetch the list of sessions terminated by nevisAuth. This polling mechanism can decrease the system performance in case several nevisProxy instances share a single nevisAuth instance, or when a nevisProxy instance contains several Esauth4ConnectorServlets connected to the same nevisAuth instance, therefore it is disabled by default. Refer to the chapter Esauth4ConnectorServlet for configuration details.