Applications' access restriction
The aim of this article is to provide an introduction on how to restrict the access of an application (or a part of it) only to registered users (or a part of them). As the Web Model is composed by site views, areas and pages, it is possible to grant the access to each of them, only to desired users. It might be necessary that a group of users can access a particular site view, or that in the same site view, different users have access to different areas or pages.
The User, Group and Module entities
The access restriction in WebRatio is done using the three default entities of the Data Model:
-
User: this entity represents a user of the application (username and password for the identification included)
-
Group: this entity represents a set of users with the same properties (access rights)
-
Module: this entity represents a logic part of the application, to which we want to restrict the access (site views, areas and pages)
and the four default relationships among them:
-
User to Default Group: it is a 1:N relationship that links a User to his default Group
-
User to Group: it is a N:N relationship that links a User to other Groups (of which shares the access rights)
-
Group to Default Module: it is a 1:N relationship that links a Group to his default Module
-
Group to Module: it is a N:N relationship
According to this model we can define several Users, each one connected to a default Group and to other Groups. Every defined Group is connected to a default Module and to other Modules. As said before, a Module is the representation of a part of the application with restricted access. In this way a user is connected to all the protected application parts to which he can have access, through the relationships with Groups (starting from the default Module of his default Group, to other Modules of other Groups). The meaning of the "User to Default Group" and the "User to Group" relationships and of the "Group to Default Module" and the "Group to Module" relationships is that when a user is identified (through the login), the information of his Default Group are gathered, along with the information of his Default Module. The result of this is that the user, after the login, is redirected to his default module. After the redirection, a user can then have access to all the protected Modules connected to his Groups.
Protected Modules and Link Visibility Policy
When you want to protect a module, you have to set it as protected in the Web Model (by checking the appropriate flag in the Properties View), before inserting it in the Module table. In the following example a protected site view, a protected area and a protected page is shown.
Moreover, when defining a module as protected, it's possible to define it's Link Visibility Policy. The Link Visibility Policy defines the behaviour of the application when a user tries to access a page to which he hasn't access.
The Link Visibility Policy are:
-
Hide Incoming Links: the links to the protected Module are visible only if the user can access it (the default condition).
-
Show Always Incoming Links: the links to the protected Module are always visible, but if an unauthorized user tries to access to it, he is redirected to the default login page.
-
Disable Incoming Links: the links to the protected module are always visible, but are disabled if the user can't access the Module.
Login, Logout, Change Group Units
The Login and Logout features itself are provided by the Login and Logout Units:
-
Login Unit: this unit receives as input a user name and a password and checks in the User table if the user exists. If the User exists, the unit performs a redirect to the Default Module of the Default Group of the User and sets the appropriate Context Parameters (UserCtxParam, GroupCtxParam). It's possible to add an OK link to the unit. This link is considered when the user that tries to log in belongs to a group for which a default protected module is not defined. So, in this case, you can redirect the user explicitely to a page, connecting the page with the Login Unit. If this link is modeled, but the current user has a default module associated, it is simply ignored and the user is redirect to his default module.
-
Logout Unit:this unit deletes the information on User and Group stored in the session parameters "UserCtxParam" and "GroupCtxParam" and redirects the User to the selected site view.
The Change Group Unit acts as a Login and Logout Units together, but without deleting the informations on User and Group (receives as input a user name and password, and redirect the user to the Default Module connected to the Default Group of the corresponding User).
WebRatio Admin Area
The Module table stores the list of all the protected modules of the Web Project. This means that everytime the Web Model is changed, adding or removing protected modules, it's necessary to add or remove the correspondent record on the Module table. These operations can be manually done by the user or they can be performed through the WebRatio Admin Area. To automatically generate the WebRatio Admin Area you have to simply follow these steps:
-
Select the tab Project in your Web project
-
Select the Security tab in the Properties View
-
Check the Enable Admin Area option
-
Enter a name for the generated page (e.g admin.do) (OPTIONAL: default is WRAdmin/Home.do)
-
Enter username and password to log into this page (OPTIONAL: default is manager/m4n4g3r)
-
Generate the Web project
It's important to note that this page is not part of your Web application and so no one of the application users can access it. It's only a private administration area that allows you to manage protected modules while your are developing the Web application. This management area shows:
-
the Application Deployment Status. Here are some information about the Web application such as the IP, the Port Number, the Application Path, the Number of Pages and Units used.
-
the Protected Modules Configuration. Here are two different lists. The first list shows the protected modules present in the Web Model but not yet inserted in the Module table. The second list shows the records of the Module table which do not have the correspondent protected module in the Web Model, and so they can be removed.