Easy User Authorization for Web Applications
Authorization is one of the primary common features of all software systems. While developing an authorization system for our ERP software, I felt that I was re-inventing the wheel since so may have written this type of code again and again in many types of software like OSs, DBMSs, HTTP Servers, File Systems etc. They have different flavors of authorization capabilities. Re-inventing is not limited with different types of systems, as it is re-implemented again and again in every enterprise web applications.
One of the missing or weak features of web frameworks is easy authorization support. In the Java EE standard, JAAS is used for authentication and authorization. I assume framework writers don’t want to re-implement this service that is already defined in Java EE stack. However, it would not be easy to use JAAS in web applications. In my opinion, JAAS is much more appropriate for desktop-based applications and component level services. In web applications, we need a new abstraction for authorization that is a URL-based authorization mechanism.
By saying “Easy Authorization”, I mean following:
- It can be used both by power users and administrators from a management module. If you have numerous users and companies using your system, you have to give the task of managing user accounts and rights to some power users.
- It should not force us to declare permissions in configuration files every time a new user or role is created. System administrators can alter these files but power users can’t access and understand these files.
- User access permissions should be grouped within role definitions (Role-based Authorization). In this way, we define an access schema only once, and easily assign it to new users many times. This is a magnificent feature. Otherwise, every time we create a user, we have to define same access rights again and again by leading to duplicate definitions which are open to errors.
- Authorization should be a transparent service for the developers. Authorization definitions shouldn’t be embedded in code. By transparent authorization, a developer doesn’t have to think the authorization aspect of the program since it is a built-in feature. In some edge conditions, the developer should also have the chance to override and change authorization behavior.
- URL-based authorization should be easily mapped to the part of the application thus removing the task of defining an authorization grant (URL) every time a new web application is written. For example, when a user has access rights for a module, a new sub-module added to this module is automatically granted to access for its users. To achieve this, you have to divide your application into sub-modules (Logical Parts). In our applications, we defined 3 levels: suite (A bunch of web applications), module (a web application), sub-module (a logical part of a web application). For example, “Human Resources” is a suite and “Payroll” is a module and “Advance Payment” is a sub-module.
- Record and field-based authorization should be defined within the same screen with module (URL) access permissions. If you are using different frameworks for persistence and web flow, AFAIK that would be impossible for now. Single point of access makes it easy to define all authorization rights
Architecture for Authorization Service
Web Application Authorization: Authorization control is carried out by an authorization service at the front of servlets. Each user request is evaluated according to its user, URL and command. If user has the authority to run this command at this URL, then command is delegated to the business layer for further execution. If user doesn’t have the permissions for the command, then a proper “Access Denied” message is returned.
Record Authorization: Authorization is also executed behind the persistence layer for record-based authorization. If user is not authorized to fetch some kind of rows, then these records are filtered out. Or a user is not authorized to edit some rows, if an update is tried on this row, then it is denied.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)