Authorization is finding out if the person, once identified, is permitted to access to a system resource (to view a page, to call a model service, ...).
This is usually determined by finding out if that person is a part of a particular group, if that person has paid admission, or has a particular level of security clearance. Authorization is equivalent to checking the guest list at an exclusive party, or checking for your ticket when you go to the opera.
As well as other software pieces, there are several patterns to implement the authorization.
One of the most commonly used is the known as Role Based Access Control (RBAC).
What's a Role Based Access Control?
Role Based Access Control (or just RBAC) is a method to control access to resources on an information system. It's a model for controlling access to resources where permitted actions on resources are identified with roles rather than with individual subject identities.
It was developed in Lion to overcome the complexities of managing individual user permissions and their assignments. The RBAC effort is motivated by concurrent efforts to:
Simplify authorization management
Reduce administrative costs
Improve security
Provide low-level authorization granularity
The operational benefits of RBAC have long been recognized since it simplifies the complexity of managing user permissions, thus providing reduced administrative cost and time.
RBAC allow us to define roles to users as well as permissions to system resources:
User: An user represents the client (commonly the end-user) of your web application. In Lion, the user is an instance of a class implementing the __IUser, but usually a class extending the __User.
Role: A role is a collection of permissions. As such, a role serves no purpose unless permissions are assigned to it. An example role might be a 'Message Board Topic Administrator.' The role might be assigned permissions to View, Update, and Delete Message Board Topic resources that have company scope. Ultimately, a user assigned the 'Message Board Topic Administrator' role would be able to view, update, and delete any topic for any message board in the company. Roles are assigned to users. Roles can also be compounded by other roles (junior roles), inheriting all their permissions.
Permission: The ability or right to perform some action on some resource, possibly only under certain specified conditions.
System Resource: A system resource is a generic term for any object represented in the web application. In Lion, a system resource is a class implementing the __ISystemResource (usually a class extending the __SystemResource).
Roles
Roles are associated to users. Basically, a role is a very flexible way to assign permissions to users.
The file app/config/security.xml is reserved to define roles and permissions. In fact, this file contains an empty role-definitions and permission-definitions sections.
However, Lion is enough flexible to allow to define those sections wherever.
Roles can also be grouped in hierarchies to make easy the permission assignment:
A junior role is when, in a role hierarchy, Role A is junior to Role B if Role B inherits all the permissions associated with Role A.
A senior role is when, in a role hierarchy, Role A is senior to Role B if Role A inherits all the permissions associated with Role B.
All roles can be defined declaratively inside the role-definitions configuration section.
i.e. imagine a configuration for a Forum Application: users can read and write messages while administrator can delete and modify messages. Of course, administrator can also read and write messages.
<?xml version = "1.0" standalone="yes"?>
<configuration>
<role-definitions>
<role id="FORUM_USER">
<permissions>
<permission id="READ_POSTS"/>
<permission id="WRITE_POSTS"/>
</permissions>
</role>
<role id="FORUM_ADMIN">
<permissions>
<permission id="DELETE_POSTS"/>
<permission id="MODIFY_POSTS"/>
</permissions>
<junior-roles>
<ref id="FORUM_USER"/>
</junior-roles>
</role>
</role-definitions>
In this example, the FORUM_USER role is junior role to FORUM_ADMIN.
Users with the FORUM_USER role will have the READ_POSTS and WRITE_POSTS permissions. It is, they will be able to read and write post in the forum.
At the same time, users with the FORUM_ADMIN role will have DELETE_POSTS and MODIFY_POSTS permissions as well as READ_POSTS and WRITE_POSTS (inherited from FORUM_USER junior role). It is, they will be able to delete and modify post in the forum as well as read and write posts.
Junior roles capability is very usefull: By adding a new permission to a junior role, all the senior roles will inherit that permission, becoming the permissions management more maintenable.
Permissions
Permissions are associated to roles (as we have seen in the previous section) and to system resources (defining the required permission to grant the access to a system resource).
In Lion, also in general, a system resource can have just one permission associated.
Instead of allowing the assignment of multiple permissions to system resources, we can define permissions hierarchies:
A junior permission is when, in a permission hierarchy, Permission A is junior to Permission B if all the system resources requiring the Permission A are accessible by having the permission B.
A senior permission is when, in a permission hierarchy, Permission A is senior to Permission B if all the system resources requiring the Permission B are accessible by having the permission A.
All permissions can be defined declaratively inside the permission-definitions configuration section.
i.e. continuing with our Forum, let's define permissions:
<?xml version = "1.0" standalone="yes"?>
<configuration>
<permission-definitions>
<permission id="READ_POSTS"/>
<permission id="WRITE_POSTS"/>
<permission id="DELETE_POSTS"/>
<permission id="MODIFY_POSTS"/>
<permission id="ADMIN_POSTS">
<junior-permissions>
<ref id="DELETE_POSTS"/>
<ref id="MODIFY_POSTS"/>
</junior-permissions>
</permission>
</permission-definitions>
</configuration>
In this example, DELETE_POSTS and MODIFY_POSTS permissions are junior permissions to ADMIN_POSTS.
i.e., roles with the ADMIN_POSTS permission will be able to access to system resources that require the DELETE_POSTS or MODIFY_POSTS permissions, because ADMIN_POSTS is senior permission to DELETE_POSTS and MODIFY_POSTS.
The PERMISSION_ALL permission
There is an special permission in Lion: PERMISSION_ALL.
This permission is a senior permission to every permission within your project. A role with this permission is able to access to all system resources. So, take care assigning this permission :)
Ah! do not define a permission with this name, is reserved for this special permission.
System Resources
As defined previously, A system resource is a generic term for any object represented in the web application.
In terms of authorization, let's focus on a system resource as an object protected by the RBAC.
In Lion, a system resource is just a class implementing the __ISystemResource, but usually a class extending the __SystemResource.
Model Services: You can protect any model service since the class used to call to the model, __ModelService extends the __SystemResource. You can also protect model services declarativelly in the model-services configuration section.
In this example, we are protecting the AdminForumController with the ADMIN_POSTS permission. So, just users with that permission could execute actions within this controller.
Note that protecting action controllers is similar to protect pages, since the client request for actions, nor pages.
Protecting Model Services
We can assign a permission to each model service declarativelly by ussing the permission tag within the model All __View derived classes are protected by the RBAC because the __View class is a child class of the __SystemResource.
In this example, we are protecting the service getPosts with the READ_POSTS permission while we are protecting the service createPost with the WRITE_POSTS permission. So, a call to the model service createPost is allowed just if the user in session has the permission WRITE_POSTS, it is, if the user has a role that contains that permission.
Protecting model services becomes interesting when we have to expose some of them, i.e. by webservices.
Protecting page zones
We can protect zones within a page by ussing the protected section component.
This component is used as a tag (protectedsection component tag) in a template, protecting the area closed between the begin and the end tag.
i.e.
<html>
<body>
This content is not protected. Everybody can see it.
The content closed here by the protectedsection tags is just
shown to users with the READ_PROTECTED_CONTENT permission.
</comp:protectedsection>
</body>
</html>
In this example, we have put a protectedsection component that requires the READ_PROTECTED_CONTENT permission.
It means that users without this permission couldn't see the content protected.
