- Authentication methods
- Available security providers
- Authorisation, Role Extraction, and other features
- Security lifecycle
The Security Module provides authentication and authorization capabilities to the search application. It supports multiple authentication providers and will pass authentication credentials on to search engines capable of handling authorization (for example, the FAST Security Access Module), providing personalisation and role based filtering. The Security Module can be extended and customised via a pluggable API.
Authentication against OAuth 2.0 services is possible using the individual authentication provider modules which simplify the configuration of OAuth parameters and deal with the differences that exist between common OAuth endpoints.
A general OAuth provider can be used by including the
twigkit.security.provider.oauth module. This requires a custom
spring-security.xml file, but it is recommended to use one of the prepackaged modules we provide for these services.
We have a method of configuring SAML authentication with a simplified process. SAML is still a complex standard and so a lot of the relevant information from the previous SAML instructions is still included here.
Appkit provides an extension for SAML based authentication. SAML is a recognised standard for authentication with many providers and implementations available.
Appkit supports a range of security providers for authentication and authorization. Typically one of these providers is used in an application:
While integration with Active Directory can be achieved using the LDAP setup, Spring Security provides a tailored security provider which makes configuring security using Active Directory easier.
The Appkit ‘Cookie Cracker’ authentication provider allows authentication against an endpoint which implements the Appkit cookie cracking endpoint protocol. This allows single sign on via a cookie value set by a 'third party' service prior to entering the Appkit application.
The Fusion security provider for Appkit allows authentication against Fusion using the Fusion Sessions API. With this provider configured, an application deployed within a Fusion defined 'realm' such as
native can securely authenticate a user against Fusion.
Appkit supports authentication via generic HTTP headers passed through from a component behind a secure firewall sitting in front of the Appkit application. If there is such an authentication component in the environment where you are using Appkit, you can configure the HTTP headers that the application will use to pick up the user’s details.
The Kerberos security provider for Appkit allows authentication using Kerberos. With this provider configured, an application deployed within a Kerberos 'realm' can securely authenticate a user against a Kerberos 'Key Distribution Center'. This module is primarily intended to simplify the process of authenticating a user silently in a Windows environment by leveraging the built in support for integrated Windows authentication in Internet Explorer. However it should be possible to use this module to authenticate the user in any Kerberos compliant environment.
Appkit allows for authentication against a server using LDAP (Lightweight Directory Access Protocol). It assumes that your Appkit application is managed as a Maven project with all project dependencies described in a Maven POM file.
Appkit can integrate with a SiteMinder single-sign-on authentication provider. SiteMinder is typically installed in a web server placed in front of the application server that runs Appkit.
The Spring Security authentication provider for Appkit interfaces with both Spring Security 3 and 4. Projects that adopt Appkit version 3 must switch to using Spring Security 4.
Authorised Spring principals become fully-qualified Appkit user profiles, along with any roles or groups that the Spring module provides. Spring Security integrates with a number of authentication protocols, including LDAP, Active Directory, Basic Authentication, Kerberos, JAAS, and others. For a full list, see here.
Apache Tomcat is an open source Java servlet container. Tomcat implements Java enterprise specs, including the Java Servlet, JavaServer Pages JSP, and WebSockets APIs.
Primary configuration is done via the
security.conf configuration file and other files in the
/conf/security/ folder. The Security Module however also supports mechanisms like Spring Security that might require its own configuration files (for example, spring-security.xml) and custom elements in
Define the security provider in
security.conf using one of the following options:
type: spring_security type: saml type: kerberos type: tomcat7 type: generic type: siteminder type: passthrough type: oauth
Spring Security is an industry standard security framework for Java. It is a popular option allowing the security to be configured initially via a simple XML file, and offers a lot of flexibility due to its integration with many different technologies, supporting a range of security standards. The spring documentation contains thorough guides to the use of Spring Security.
By default Appkit applications are configured to use Spring Security with a simple hard-coded set of credentials in the provided
spring-security.xml file, but you can see some other common configurations defined here. Further documentation on configuring Spring Security can be found here.
Appkit can be configured to use Spring Security for both authentication and role extraction.
In this case the application server is responsible for authentication such as:
Internet Information Server and Integrated Windows Authentication
The application server can be configured to pick up the user’s credentials when the request is forwarded from a 'front-end' like IIS or Apache. In cases where authentication is done by the container it is still possible to do role extraction using Active Directory or LDAP for the user provider (see below).
The generic security option uses getRemoteUser() or the REMOTE_USER variable provided through the servlet API. This is for authentication only, but it can be combined with other methods for picking up the roles assigned to a user and submitting them to the search platform (see Active Directory and LDAP role extraction below).
You can add your own SecurityProvider which would be responsible for providing the user identity to Appkit. To do this, implement the
twigkit.security.SecurityProvider interface and bind the class using Guice in your custom module.
After the user’s identity has been established during the authentication stage, it is possible to carry out further authorisation tasks such as role extraction or adding other metadata about the current user.
Appkit Security Module comes with pre-built filters to handle mapping between user names and domains. It is also possible to provide your own logic during this phase to deal with specific scenarios for determining a user’s credentials and details before rendering the page or passing them to the search platform.
When the Security Module is installed, every request made to Appkit is filtered through the configured authentication provider. Credentials are added to the request via a ThreadLocal variable. Authentication providers can be container managed, single sign on or configured for form based authentication in Appkit. You can create your own authentication provider by implementing and binding the twigkit.security.SecurityProvider class.
2. Role Extraction
Next step in the filter chain can handle role/group extraction for the authenticated user. This is frequently done via an Active Directory/LDAP lookup. The role extraction mechanisms will add the roles for the user to the User object.
When the Security Module is used queries should be created using the secure version of the Query tag. The secure query tag will provide a reference to the user that is logged in and pass the identity on to the search platform if necessary. The Security Module also provides a number of processors and utilities for adding filters to the query based on business rules or identity/role information.
The User and Role information is available in the user interface. Using the Security Conditional tag you can customise the view to the user that is logged in.