Authentication and Authorization

Authentication is a process of verifying whether someone is who he claims he is. It usually involves a username and a password, but may include any other methods of demonstrating identity, such as a smart card, fingerprints, etc.

Authorization is finding out if the person, once identified, is permitted to manipulate specific resources. This is usually determined by finding out if that person is of a particular role that has access to the resources.

How PRADO Auth Framework Works

PRADO provides an extensible authentication/authorization framework. As described in application lifecycles, TApplication reserves several lifecycles for modules responsible for authentication and authorization. PRADO provides the TAuthManager module for such purposes. Developers can plug in their own auth modules easily. TAuthManager is designed to be used together with TUserManager module, which implements a read-only user database.

When a page request occurs, TAuthManager will try to restore user information from session. If no user information is found, the user is considered as an anonymous or guest user. To facilitate user identity verification, TAuthManager provides two commonly used methods: login() and logout(). A user is logged in (verified) if his username and password entries match a record in the user database managed by TUserManager. A user is logged out if his user information is cleared from session and he needs to re-login if he makes new page requests.

During Authorization application lifecycle, which occurs after Authentication lifecycle, TAuthManager will verify if the current user has access to the requested page according to a set of authorization rules. The authorization is role-based, i.e., a user has access to a page if 1) the page explicitly states that the user has access; 2) or the user is of a particular role that has access to the page. If the user does not have access to the page, TAuthManager will redirect user browser to the login page which is specified by LoginPage property.

Using PRADO Auth Framework

To enable PRADO auth framework, add the TAuthManager module and TUserManager module to application configuration,

<service id="page" class="TPageService"> <modules> <module id="auth" class="System.Security.TAuthManager" UserManager="users" LoginPage="UserLogin" /> <module id="users" class="System.Security.TUserManager" PasswordMode="Clear"> <user name="demo" password="demo" /> <user name="admin" password="admin" /> </module> </modules> </service>

In the above, the UserManager property of TAuthManager is set to the users module which is TUserManager. Developers may replace it with a different user management module that is derived from TUserManager.

Authorization rules for pages are specified in page configurations as follows,

<authorization> <allow pages="PageID1,PageID2" users="User1,User2" roles="Role1" /> <deny pages="PageID1,PageID2" users="?" verb="post" /> </authorization>

An authorization rule can be either an allow rule or a deny rule. Each rule consists of four optional properties:

When a page request is being processed, a list of authorization rules may be available. However, only the first effective rule matching the current user will render the authorization result.

In the above example, anonymous users will be denied from posting to PageID1 and PageID2, while User1 and User2 and all users of role Role1 can access the two pages (in both get and post methods).

Since version 3.1.1, the pages attribute in the authorization rules can take relative page paths with wildcard '*'. For example, pages="admin.Home" refers to the Home page under the admin directory, and pages="admin.*" would refer to all pages under the admin directory and subdirectories.

Also introduced in version 3.1.1 are IP rules. They are specified by a new attribute ip in authorization rules. The IP rules are used to determine if an authorization rule aplies to an end-user according to his IP address. One can list a few IPs together, separated by comma ','. Wildcard '*' can be used in the rules. For example, ip="192.168.0.2, 192.168.1.*" means the rule applies to users whose IP address is 192.168.0.2 or 192.168.1.*. The latter matches any host in the subnet 192.168.1.

Using TUserManager

As aforementioned, TUserManager implements a read-only user database. The user information are specified in either application configuration or an external XML file.

We have seen in the above example that two users are specified in the application configuration. Complete syntax of specifying the user and role information is as follows,

<user name="demo" password="demo" roles="demo,admin" /> <role name="admin" users="demo,demo2" />

where the roles attribute in user element is optional. User roles can be specified in either the user element or in a separate role element.

Using TDbUserManager

TDbUserManager is introduced in v3.1.0. Its main purpose is to simplify the task of managing user accounts that are stored in a database. It requires developers to write a user class that represents the necessary information for a user account. The user class must extend from TDbUser.

To use TDbUserManager, configure it in the application configuration like following:

In the above, UserClass specifies what class will be used to create user instance. The class must extend from TDbUser. ConnectionID refers to the ID of a TDataSourceConfig module which specifies how to establish database connection to retrieve user information.

The user class has to implement the two abstract methods in TDbUser: validateUser() and createUser(). Since user account information is stored in a database, the user class may make use of its DbConnection property to reach the database.

$Id$