Why 4 Levels of Authorization Makes Sense
In application development, adding security features can include requirements for authentication and authorization. Authentication identifies the user. Authorization checks and filters what the user can do. Authentication is mostly easy. Authorization though can be a little bit tricky.
A simple application with authentication can be enough. Anyone who can login can access and do anything that the application has to offer. However, for applications designed to accommodate more than one type of users, adding authorization provides additional levels of security, not just at the application level, but, more important, down to the data level itself.
A typical enterprise application can host modules. Each module can have different purposes. For example, you can have a module to maintain account information, another for transactions and, perhaps, another for finance. Each module may be designed for specific departments or groups in the company. For example, the accounts module may be for account managers, the transactions module may be for operations, and the finance module for accounting.
However, you can also have the executives and management interested in accessing two or more, if not all, of these modules. You can also have support, testers and developers who may have full access. Furthermore, within each of these different departments/groups, there may be people who are interested only in reviewing data. Some may be required to add or edit data. Still some may be allowed to delete, restore or purge data. And then there may also be users who are designated to maintain master lists, lookups and other data shared by more than one module.
Roles-/claims-based authorization can provide ways to define simple, single-dimensional list of "roles" or "claims". This can work, for example, for as long as all possible roles/claims and their variations, based on what they can or cannot do, are given names. Based on the examples I've been describing so far, it's going to be a crazy long list.
IBM Tivoli Access Manager (TAM) has an authorization service that works on 4 levels: groups, root, entitlements and permissions. When authorizing a user, you MUST check as follows: if a user is a member of this group, is the user entitled to this root? If so, what are the user's entitlements under this root? For each of these entitlements, what are the user's permissions?
Thus, with TAM, when defining an application's authorization setup, you don't create a list. Rather, you create a matrix.
This policy-based authorization makes a lot of sense. It's complex, but much simpler when the needs grow, compared to maintaining a long single-dimensional list. The authorization matrix can be intimidating at first, but once all setup, it is actually much easier to understand, maintain and implement.
A simple application with authentication can be enough. Anyone who can login can access and do anything that the application has to offer. However, for applications designed to accommodate more than one type of users, adding authorization provides additional levels of security, not just at the application level, but, more important, down to the data level itself.
A typical enterprise application can host modules. Each module can have different purposes. For example, you can have a module to maintain account information, another for transactions and, perhaps, another for finance. Each module may be designed for specific departments or groups in the company. For example, the accounts module may be for account managers, the transactions module may be for operations, and the finance module for accounting.
However, you can also have the executives and management interested in accessing two or more, if not all, of these modules. You can also have support, testers and developers who may have full access. Furthermore, within each of these different departments/groups, there may be people who are interested only in reviewing data. Some may be required to add or edit data. Still some may be allowed to delete, restore or purge data. And then there may also be users who are designated to maintain master lists, lookups and other data shared by more than one module.
Roles-/claims-based authorization can provide ways to define simple, single-dimensional list of "roles" or "claims". This can work, for example, for as long as all possible roles/claims and their variations, based on what they can or cannot do, are given names. Based on the examples I've been describing so far, it's going to be a crazy long list.
IBM Tivoli Access Manager (TAM) has an authorization service that works on 4 levels: groups, root, entitlements and permissions. When authorizing a user, you MUST check as follows: if a user is a member of this group, is the user entitled to this root? If so, what are the user's entitlements under this root? For each of these entitlements, what are the user's permissions?
Thus, with TAM, when defining an application's authorization setup, you don't create a list. Rather, you create a matrix.
- The group can refer to a department/group or roles (ex. app1_sales, app1_operations, app1_finance, app1_admin, etc.).
- The root can refer to the application (ex. /enterprise/app1).
- The entitlements can refer to modules and/or actions in the application (ex. /enterprise/app1/accounts, /enterprise/app1/transactions, /enterprise/app1/finance, /enterprise/app1/maintenance, /enterprise/app1/admin, /enterprise/app1/reports, etc.).
- Each of these entitlements can be assigned permissions (ex. read, add, update, delete, etc.).
This policy-based authorization makes a lot of sense. It's complex, but much simpler when the needs grow, compared to maintaining a long single-dimensional list. The authorization matrix can be intimidating at first, but once all setup, it is actually much easier to understand, maintain and implement.
Comments
Post a Comment