About Role Authentication
Role security is based on the type of user accessing an application, and not directly on the user's exact identity. A role is basically the usage characteristic of a group of users, such as Application_Admin, Application_Vendor, or Application_Employee roles.
In contrast to security based on strict user identity, where a Netscape Application Server authenticates a user by their user name and password, role security only authenticates the existence of a role and the permissions of that role. Role security does not authenticate the actual user. The application developer must manage how users are authenticated and determine what role a user has. This is typically done by referencing a database table that would keep track of actual user-identity information. The application developer is responsible, in this case, for managing and accessing the user records in the database.
For example, the application developer constructs a database table that stores the user's username and password, obtained from a login screen, along with other pertinent information, such as credit card numbers, shipping address, and so on. Along with this information, is the user's role, assigned the first time the user logs in. When the user logs in, the application can verify the user and their password, and link this information with their role for further use within the application. For first time users, the application can quickly create a new record and add that user to the database.
As the user traverses through the application, certain AppLogic objects might require a secure login, which the loginSession( ) method provides. Before the loginSession( ) method is called, the application would obtain the user's role from the database table, also verifying that the user is valid. Once the role is known, it is passed into the loginSession( ) method. The Netscape Application Server is now aware of the user's role for the remainder of the session or until logoutSession( ) is called.
The application developer determines the roles for the application. For example, if the application is for purchasing products over the Web, and a user entered through the publicly available access page, that user's role might be Public_User. This role might change later, if, for example, the application determines that the user is actually a vendor or a partner. The updating and assignment of roles is under application logic control and, as long as the role is defined with the Netscape Application Server, the user obtains the appropriate privileges.
How Netscape Application Server Stores and Manages Roles
A role and a user are stored and verified by Netscape Application Server in the same way, using the local registry. Implementing role security requires less administration maintenance than explicit user security because you do not have to make updates in the Netscape Application Server Administrator for every user. Mapping users to roles is the responsibility of the application developer and is done in the database through application code. In addition, the number of roles you create for an application is typically much fewer than the number of users that use the application.
Role security is the most scalable way to provide security. It requires more planning from the application developer to create the user database table. Once the database table is created, however, all further maintenance of users is handled by the application. Role security is a must for Intranet and Internet applications with a large number of users where tracking the actual users in a database table is required for scalability.
|