Role Creation Guidelines

Because roles include privileges that are necessary to enable a user to perform a task, the role name is typically some derivation of the application task or job title (as in my developer example).

The following are general guidelines for creating roles:

• Create roles for each application task.

• The name of an application role should correspond to the task within the application (for example, GL_ACCOUNTING).

• Assign the privileges necessary to perform the task to the application role.

• Whenever you create a role for a type of user, the name of the role should correspond to the job title (for example, GL_CLERK or AP_CLERK).

• Grant application roles to user roles.

• Grant user roles to users.

• Modify application roles by adding new required privileges.

Using Passwords with Roles

Authorizing a role using passwords adds an extra level of security to the enabling of the role. It may mean that a user has to deliberately think about the fact that she is taking the steps to change from one role to another. For example, instead of "just" doing the standard job associated with an accounting clerk (a role that might have read privileges to the payroll information), the user changes to the role of payroll clerk (a role that enables that user to write to the tables and issue payroll checks).

When a user enables the password-protected role, the user logs in to the program that has been provided with the password, and the user never has to know or enter that password. In this way, security can be protected, and the user can still perform the check-writing function.

And we find ourselves again at the data dictionary where we can locate information on anything.