IBM WebSphere V5.0 Security - CGISecurity

For example, in a bank account object, we can have different methods (transfer,
deposit, getBalance, setInterest, etc.). The access right can be granted on the
basis of the roles of the users within the organization. A bank teller can have
access to the getBalance method but not to setBalance, while a manager can
have access to both methods.
Table 2-1 Example of a Role Access Control List
Resources Bank teller role Manager role
getBalance method yes yes
setBalance method no yes
Capability list
Associated with each user is a list of resources and the corresponding privileges
held for the user.
In this case, the holder is given the right to perform the operation on a particular
resource.
In the previous example of the bank account object, the access right is granted to
the user if the resource is listed in the user’s capability list.
Table 2-2 Example of a capability list
Roles getBalance method setBalance method
Bank teller role yes no
Manager role yes yes
You will find the two tables shown above very similar, but the rows and the
columns are switched. Actually, this is the difference between the two
approaches. We have two sets: roles and resources. In the first case, roles are
mapped to resources, while in the second case resources are mapped to roles.
The access control list is exercised generally, because managing security for
certain resources is easier and more flexible than mapping resources to roles.
Role-based security
Roles are different levels of security that relate to a specific application. For
example, in a banking scenario, different employees have different roles, so the
security access that each employee will require to complete the tasks in a Web
application will also be different. In a roles based authorization model, the roles
for a given application are developed as an application is developed. As a user
base for the application is established, one of three things happens.
Chapter 2. Security fundamentals 11