User authentication and authorisation

Brief outline

How users are authenticated by the client and client-direct components takes one of two techniques provided by their parent client-shared component. At runtime the technique used is determined by the use of Spring profiles.

1. “prepopulated user authentication”

   The off-the-shelf portal authentication mechanism which makes user of manually populated user databases.

   This mechanism is relatively straightforward, in that the users.sql files (see client and client-direct) containing usernames, passwords and roles, are created and populated during portal installation and manually updated thereafter.

   Only when using this option do potential portal users have the ability to register to use the portal using the portal interface.

2. “bespoke user authentication”

   The provision of a bespoke authentication mechanism (e.g. NTLM, Active Directory) by the site itself.

   Whilst the authentication mechanism may already be available on-site, there will need to be a bespoke filter (see Request Filtering) created which interfaces with this mechanism.

Task responsibility (for “bespoke user authentication”)

The primary objective of this activity most likely involves the IT personnel determining how to control access to the client and client-direct user interfaces by intercepting requests (see Request Filtering) to determine user identity and return a browser redirect to site authentication mechanisms before the user is granted access.

The IT people involved will need to have some experience of Java software development (including Spring), as well as XML formats.

Additional detail

Request Filtering

The client and client-direct components both make use of Spring Security’s springSecurityFilterChain FilterChainProxy by virtue of the src/main/webapp/WEB-INF/web.xml filter naming. This mechanism intercepts all incoming requests and passes control to a variety of filters which can take whatever action is appropriate for the circumstances, e.g. accept (and pass the request to the next filter in the chain), or reject (and perhaps show a default page or redirect to an authentication mechanism).

Amongst these filters there are some standard checks such as for security (e.g. CSRF) and valid sessions, but there can also be site-specific checks which can, for example, check for the presence of site cookies or query local authentication/authorisation mechanisms, e.g. NTLM. Equally, some portal pages could be deemed to be available for perusal by any visitor, e.g. such as in appCtx.noSecurity.xml

If a request arrives at a portal from an unauthenticated user hoping to visit restricted access areas then a site-specific filter (e.g. sample.appCtx.sitePreauthFilter.xml) injected into the springSecurityFilterChain (e.g. custom-filter in sample.appCtx.bespoke.xml) will reject the request and most likely forward the user to the site’s authentication mechanism.

Authorisation mechanisms

Access to certain areas of the portal are controlled by the “Role”s which were assigned to the user at authentication time.

As a general rule all users accessing the client or client-direct portals must, unless they are accessing unrestricted areas, be in the ROLE_USER group (e.g. as determined by sample.appCtx.bespoke.xml or appCtx.prepopulated.xml).

Currently the only supported roles are defined in Role.java

• ROLE_USER
  Generally every portal visitor must be authenticated and assigned this “Role”.
• ROLE_POWER_USER
  Generally assigned to users with access to certain “elevated privileges” functionality, such as entering ion channel spread values, or uploading CellML files.
• ROLE_ADMIN
  Assigned to the person(s) responsible for administrative portal duties.

See also

Portal feature access