Authentication
Digest
Login Authentication is the process of checking usernames and passwords provided at log-in against authorized credentials. It is accomplished by CMS in one of three ways:
- Built-in authentication, which stores user information in the database used for other CMS data storage
- LDAP authentication, accomplished by querying your LDAP-enabled directory server (Active Directory, OpenLDAP, etc.) to retrieve user information.
- Custom login authentication. This authentication is determined by the administrator of the client network. Please consult your network or CMS administrator for more details.
Concept
Built-In Authentication
With the built-in authentication, the administrator must create an account for each user from within the CMS before they can access the system. This is accomplished from the 'Users, Groups, and Roles' option in the 'Administration' area.LDAP Authentication
Using LDAP authentication, on the other hand, the CMS authenticates users against a directory on an LDAP-enabled server (usually separate from the server housing the CMS), which could be a pre-existing directory server. This allows you to maintain users for the CMS and other purposes centrally, without having to create multiple accounts for each user.
Custom Authentication
A custom authentication will vary depending on the particular circumstances. Typically, there is a single sign-on service, which will authenticate a user against a system separate from Cascade Server. This is usually the same process a user might go through to check organizational email or to use other distributed software.Technical
Authentication Resources
- LDAP/Active Directory »
This section provides information on configuring LDAP and Active Directory.- Set LDAP Imported Users as Using Custom Authentication
This information is important for users of 4.2 and higher. - File Details
The CMS enables the LDAP-enabled enterprise to effectively integrate already-established user-group relationships into the system user-group information architecture. - Options and Schedule Element
This page lists details of the <options> and <schedule> element in the LDAP config file. - Policies Element
This page lists details of the <policies> element in the LDAP config file. - Running the LDAP Migrator
Run the LDAP Migrator either manually or automatically. - Using LDAP with SSL
This information is important for users of 4.1 or higher. - Custom LDAP Binding Modules
This information is important for users of 4.1 and higher.
- Set LDAP Imported Users as Using Custom Authentication
Custom User Authentication Plugin
Users in Cascade Server can be authenticated in one of three ways:
- Normal
- LDAP
- Custom
The Normal authentication works as expected, comparing supplied the user-supplied password against the password stored in the Cascade database. Note that these passwords are hashed to prevent accounts being compromised.
LDAP authentication applies to users imported from the LDAP migration tool. These users log in the same way as other users, except that instead of comparing a password against the Cascade database, Cascade will attempt to access the LDAP store using the supplied credentials. If successful, authentication is successful and the user logs in.
Custom authentication refers to a plug-in architecture Cascade exposes to allow 3rd party authentication frameworks to authenticate users in a variety of ways.
To support custom authentication, Cascade server provides a series of hooks into the authentication life cycle. Developers coding such a custom plug-in will have the ability to redirect the browser to arbitrary URLs (such as a single sign on web application).
Plug-in Development
Download the custom authentication API.
All custom authentication modules must implement the interface: com.hannonhill.cascade.model.security.authentication.Authenticator
This interface defines two main methods:
and
The redirect() method is called by the Cascade authentication framework based on what phase of the authentication life cycle is active. The AuthenticationPhase is an enum with two values: LOGIN and LOGOUT.
For the LOGIN phase, Cascade first instantiates the custom authentication module and calls redirect with the LOGIN authentication phase parameter. At this point, the module will redirect to an external webapp to perform the authentication, at which point the authentication web application should redirect the browser back to Authenticator.AUTHENTICATION_URI.
Cascade will then invoke the module once more and call authenticate(). The module at that point should know whether or not the user was successfully authenticated, and should everything go well, the module should return the username of the successfully authenticated user. At this point, Cascade establishes a user session for the authenticated user and the user is considered to be logged in to Cascade.
The other phase, LOGOUT, is called when the logout link is clicked and after Cascade invalidates the user session. The typical behavior here is for the custom authentication module to redirect the browser back to the external authentication web application.
It is important to remember to not store state in the authentication module using instance members. Each call on the authentication module is made after a fresh instantiation, and as such, data stored as instance members will be lost in between invocations.
The authentication module code is typically bundled into a JAR file and placed in the $tomcat_home/webapps/ROOT/WEB-INF/lib directory. After bouncing the app server, the custom classes should be available.
A configuration file must be created to tell Cascade how to load the custom plug-in:
To use the configuration click Tools -> System -> Configuration ->Custom Authentication Configuration, then paste the contents of the configuration file when prompted.