Skip navigation links

Package uk.ac.ed.epcc.webapp.session

The package uk.ac.ed.epcc.webapp.session contains classes related to authentication, session management and logins.

See: Description

Package uk.ac.ed.epcc.webapp.session Description

The package uk.ac.ed.epcc.webapp.session contains classes related to authentication, session management and logins.

The most important of these is the SessionService which is an AppContextService that represents all known information about the current logged in user. This is usually a sub-class of AbstractSessionService

Known users of the system are usually recorded using some sub-class of the AppUser class and its associated factory AppUserFactory. In most cases access control logic should use the SessionService rather than an instance of the AppUser. This is because the SessionService also has access to session specific state and information from the container. In principle it is possible to not record users in the database at all and only use container authentication.

Typically there is a unique name that can be used to identify a system user. Frequently there is more than one such name and the exact configuration depends on local requirements. These unique names are therefore implemented as AppUserNameFinder Composites. These names play an important part in authentication. When using container level authentication the identity provided by the container is mapped to a database record by name. Container level authentication can be set globally or multiple authentications mechanisms can be supported via explicit authentication servlets at different URLs. We can also support password based authentication if the AppUserFactory contains a Composite registered as a PasswordAuthComposite. Password based authentication can be by an explicit login form or using basic-auth.

There are two key abstractions for the permissions model:

Roles can be set to be togglable. In this case the user with the role can turn it on and off during their session. The role mechanism is also a key extension point and can be customised by creating a new SessionService class. Though role settings are normally stored in the database, roles defined in the servlet container can be imported into the application and made available. In addition model specific information (like project membership) can be made available as roles.

Relationships are accessed as filters. The SessionService can generate a filter for all objects of a certain type that the current user has a specified relationship with. Similarly it can generate a filter for people that have a relationship with a specified object. Most of this information comes from model objects and is frequently a combination of data from different sources. classes can contribute to relationships by implementing AccessRoleProvider.
 
Skip navigation links