I am an ERP Project Manager for 7 years within a big company which has many subsidiary companies. As ERP team, we are not only implementing ERP software but also writing our own ERP with the target that we sell this product in the future. Our platform is Java and our applications are web-based. Ibrahim has posted 11 posts at DZone. View Full User Profile

Easy User Authorization for Web Applications

07.21.2009
| 10964 views |
  • submit to reddit

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

AuthorizationService
Published at DZone with permission of its author, Ibrahim Levent.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Alessio Spadaro replied on Tue, 2009/07/21 - 4:43am

What about Apache Shiro? (formerly known as Apache Ki (formerly known as JSecurity (formerl...)))

Jean-Philippe Toupin replied on Tue, 2009/07/21 - 7:14am

I also find Apache Shiro very interresting. What worries me is that there is no documentation at all.

Justen Stepka replied on Wed, 2009/07/22 - 10:50am

You may want to check out Atlassian Crowd.

It handles coding common authentication task very easily for you. Out of the box connects exist for Spring, JAAS, etc and you can tie in your existing authentication services (LDAP, custom DB, etc).

Connectors exist for popular services you may already have on your network as well, such as Apache HTTP server.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.