Skip to content

Proposed Authentication

Jump to bottom
Alejandra Gonzalez-Beltran edited this page Jun 18, 2019 · 4 revisions

The design below shows a mechanism for allowing the web frontend application to be flexible enough to handle a wide variety of authentication types. It has been designed in a modular way to allow replacements of components by implementing a simple API interface. This is to avoid having a single application trying to meet all the requirements in a single code base.

The diagram shows the basic flow that would happen when a user logins and then makes use of a plugin.

Auth Client

This is the authentication interface in the browser and is the interface the user will use to login.

Auth Gateway

This service provides an API interface to accept credentials from the Auth Client. These could be a username and password or a token e.g. OAuth. If needed, it uses the credentials to authenticate against other systems such as LDAP or ICAT. Upon successful authentication, the Auth Gateway can submit a request for a new session id to the Session Manager. Along with this request it can send a payload of data to be assigned to that session e.g. username, ids etc.

Session Manager

This component is responsible for generating a session token and storing a payload to it. Presenting it with a valid token will return the payload data. It can also allow a session to be destroyed and refreshed/extended.

Plugin Serverside

This is the serverside component to the plugin. It can authenticate the session id against the Session Manager and retrieve the session payload.

Logic Flow

The steps below show the flow of logic for a user logging in an using a plugin.

  1. A user logins via their web browser
  2. Credentials are passed to the Auth Gateway
  3. The Auth Gateway will validate the credentials. This may include passing them onto another system eg. ICAT
  4. The Auth Gateway will request a new session id from the Session Manager and store a payload against this session id in the Session Manager
  5. The session id will be passed back up into the browser where it is stored as a HTTP cookie
  6. When a user makes a call via a plugin, the session id contained in the HTTP cookie will be passed down to the plugin serverside which can use it to 1) verify and identify the user, 2) access the payload data
  7. Response (and payload) are sent back to the Plugin Serverside.

Session Payload

Below is the type of payload data that can be attached to the session.

session id : createtime expiretime primary_name primary_id icat_session_id oauth_token

Auth Plugin?

The Auth Client and Auth Gateway could be package up together in a similar way to the plugins - a client side and server side component. The main root application in the browser would read in the location of the authentication plugin and load it.

Clone this wiki locally