Chapter 10
Authentication & Authorization
JMatter comes built-in with authentication and authorization services.
When launching a JMatter application for the first time, the framework
will create two roles (administrative and default) and two corresponding
users: admin (with admin privileges), and 'johndoe' with default privileges,
as shown in the figure 38.
Figure 10.1: Initial Users and Roles
The framework provides two model objects: User.java and Role.java,
that are constructed according to JMatter's own conventions for model
objects. The icons used for these types follow the same convention:
you will find in the path jmatter/resources/images the corresponding
icons used by the framework. In the case of User, you will
find three variants: an icon for a single user, a plural version,
and a state-specific icon for locked users (UserLocked32.png).
Users and Roles are modeled in a bidirectional one-to-many association.
By default, when creating a new user, the user will be associated
with the default role.
Passwords are hashed using the MD5 algorigthm, and it is this hash
which is stored in the database.
Upon application launch, the application is in logged out state,
and a login dialog is presented. Three invalid login attempts by default
will cause the user account in question to lock, requiring an administrator
to reset the user's password. Password resetting is implemented as
a JMatter Command (@Cmd) and so is accessible directly from
the user interface (assuming you have the proper permission).
Upon successful login, the user's classbar is fetched from database
(upon initial login, the classbar is defined from the template file
class-list.xml) and presented in the user interface.
Again, assuming the proper permissions, one can create new users,
new roles, assign users to a role, and go about performing whatever
activities are necessary to manage authentication-related information.
10.1 Autologin
In some situations, one might be interested in developing a application
that does not care for or require authentication. For such cases,
JMatter can be configured to automatically log in as a specific user
upon launch, removing the need for users to manually authenticate.
To configure a JMatter application with autologin, edit the application's
src/applicationContext.xml as follows:
-
<bean id="app-session" class="com.u2d.app.AppSession">
<property name="app" ref="application" />
<property name="viewMechanism" ref="view-mechanism" />
<property name="autologinas" value="admin" />
</bean>
The important line is the autologinas property, which directs
JMatter to turn on autologin and to automatically log the user in
as the user admin, in this particular case.
10.2 Authorization
Authorization governs who can perform what actions. Authorization
in JMatter is specified by role. JMatter comes complete with an authorization
implementation, all driven from the user interface.
The starting point is an application where everything is permitted.
Authorization is specified then by applying a series of restrictions
from this initial state. When a user logs in, the set of restrictions
corresponding to the user's role are fetched from the database and
applied to the system. Upon logout, the restrictions are lifted, and
reapplied on subsequent login, again according to the new logged in
user's role's restrictions.
Restrictions can be applied to both commands and fields. Commands
can be disabled, in which case, they disappear from the user interface:
from context menus, from the button panels on form views. Fields can
be marked hidden or read-only, per role.
To specify the authorization policy, JMatter defines the command Manage
Restrictions, defined on all types, as shown in figure 39.
Figure 10.2: Managing Restrictions
Just like Form Views are dynamically rendered, based on the structure
of model objects, so is this view. When a new role is created, a new
column will appear in this view. When a new command or field is added,
a new row will be added to the corresponding table.
Here we see that existing administrative commands are already marked
restricted for the 'default' role. For example, the ability to create
a new role, to edit or delete roles, is prohibited. Furthermore the
ability to define restrictions on roles is likewise prohibited. Finally,
the role type's Open command is prohibited as well, restricting
access to inspection of the type's metadata from the user interface.