Security and Customisation
Security considerations have not been mentioned much, up to this point. Security
is deeply ingrained in the service and web framework via the BeNOW Security API.
This API is a light wrapper for security concerns, and implements concepts such
as User, Permission, Role and Group.
The security api is discussed in depth in the
Using the Security API
and Creating Secure Services
tutorials. You should read these tutorials to be familiar with security concepts.
Here, we'll discuss how security fits into the web framework, and how security can be
integrated with your application.
Security Objects
As described in the Using the Security API tutorial,
the primary security interfaces are User, Permission and Role. From a web perspective,
a User is someone accessing the site. It may be the anonymous user (a visitor that
has not yet authenticated), the admin user (the initial install user) or an
authenticated user. Users may have permissions and roles assigned to them. Permissions
are used to determine what a user can do, and roles are collections of permissions. They
can be assigned to a specific user to guide what that user may do. For example,
Fred may be in a data maintainer role, but also be allowed to delete certain objects.
As encountered when the framework was first run, the database does not exist and the administrator
has not been created. As an administrator is required for management, a special mode is
triggered where all requests redirect to a page where the administrator password can be defined:
After successful registration, the following message is shown
and the web framework becomes fully functional.
Security Pages
The web framework provides accessors to security functionality. The security pages
provide management of users, creation of roles and assignment of permissions. The
security page can be found as the 'security' submenu item of the Administration menu,
when logged in as the administrator:
New users can be added by clicking the create icon:
Once created, permissions can be added to the user:
and the user will pass assertion of the assigned permissions:
A similar process can be done to create roles, assign permission to roles and
assign roles to users.
As mentioned in the security api tutorial, the special user 'template:registered' can
be modified to include roles and permissions which will automatically be assigned
to newly created users.
Login and Registration
The login page can be found by clicking the login link in the top right
(of the default layout). It provides the ability for users to login, as well as new
user registration, sending of confirmation and password resetting:
Customisation
You might want to customise the security presentation to better fit your application. Typical
customisations might involve the surfacing of the login box to the template, so that it shows
on all pages, or to remove or replace the registration or confirmation procedures. The login
page can be customised by overloading the /admin/security/login.page. The
development page can be used to extract and overload the content.
Go to the development page and view all pages including those in resources, select /admin/security/login.page
and hit edit.
You'll be prompted to confirm extraction with a page similar to this:
Choose 'Make a copy and customize...' and /admin/security/login.page will be
extracted from benow-web.jar to html/admin/security/login.page.
It can then be customised and will override the login.page in benow-web.jar:
The entire login procedure can be overridden, but usually it is best to modify what is already there.
The login procedure calls the org.benow.web.security.SecurityWebService.login(String,String)
method, and that should be preserved (or duplicated), in order to correctly authenticate and associate web users.
User Modules
Another typical application requirement is to associate data with users. This is done in the Security API via
User Modules, as discussed in the security tutorial.
UserModules are classes which are associated with users and can hold custom, application specific data. The modules can then
be fetched and the data accessed and updated.
These user modules can be fetched and presented within the application. I'll demonstrate this now by extending population and
display of the address user module by overriding the user security page.
First create the user module as describe in the security tutorial
The new user page can then be extracted for customisation as shown above. I've moved it to html/sample/security.page.
The address fields are added:
and it now submits to a new service method, CustomSecurityService.update(User,AddressUserModule)
The user and address user module are received from the form, the user is added via the WebSecurityService,
a new address user module is created for the user,
and the user is updated. The address information is now associated with the user, as can be seen in the
user view page, which has been customised to show information from the address user module:
Similarly, your pages can be made to display information associated with the user.
Additionally, every dynamic page (*.page)
has the user template parameter (<xsl:param name="user">) assigned on transform,
and so the user (and user module) information can be accessed in every page, if such behaviour is desired.