KeyMaster SignOn Framework

You can use use the KeyMaster SignOn Framework to implement a web-based sign-on system. The implementation uses Java Servlets and Filters to protect the generation of KeyMaster user credentials tokens. It can also protect other web resources as required.

The framework is supplied as a class library that you extend to implement single-factor user authentication (1FA) and, if required, two-factor authentication (2FA). The extensions you implement would typically make use of the user authentication and 2FA services provided by your existing security system.

The framework consists of three main components:

The following diagram shows, in outline, how the KeyMaster SignOn framework works:

The client (a Web application, such as Caplin FX Professional) sends a sign-on request for a user to the Web server and this request is routed to the SignOn servlet for authentication. It’s likely that you already have a security system in place that handles user authentication, so you’d implement the SignOn servlet to use the services provided by that system. The authentication process could be just to verify a username and password (single-factor, or "1FA", authentication), or it could involve additional verification steps, such as sending the user a secondary login token in a text message to their phone (this is called two-factor, or "2FA" authentication). The level of authentication required (1FA or 2FA) for a particular user would typically be determined by the security system.

The SignOn servlet handles the sequence of HTTP requests and responses involved in the sign-on sequence. Requests can contain parameters in JSON format and responses are also in JSON format. The servlet also records information about the state of the sign-on sequence in a SessionData object that is available to an Authentication Filter.

Once the user has been successfully authenticated and has logged on to the Web application, the Web application subsequently needs to log the user on to Liberator, so it requests a KeyMaster user credentials token. The token request is intercepted by the Authentication Filter, which sits above resources, such as the KeyMaster servlet, and protects each resource by checking that the user’s session is authenticated to the required level before passing any URL request on to the resource. The filter uses information in the SessionData object to determine whether the request should be authorised. The user named in the request must be a valid, previously signed on user, and they must have been authenticated to at least the level configured in the Filter (for example, 1FA or 2FA).

When the request has been authorised and it’s for a KeyMaster user credentials token, the Filter passes it on to the KeyMaster servlet. KeyMaster generates the token and sends it back to the client, which uses the token to log on to the Liberator (this last step isn’t shown in the diagram).