Implementing Role Based Access Control - RBAC
A few years ago, we met with our business analysts to discuss security for our application.
Our goal was to implement our own authentication mechanism for the web-based or user-interface
portion of the application.
We defined authentication security as "access rights to resources of the application".
After some initial discussion, one of our business analysts suggested we look for an
industry standard to guide us in implementing authentication in our app.
After some research, we came across something called RBAC, Role Based Access Control.
RBAC is an approach to restricting application access to authorized users.
It was first suggested in a paper titled, "Role-Based Access Control" by D.F. Ferraiolo and D.R. Kuhn, D.R. (October 1992).
Today the NIST, National Institute of Standards and Technology, an Agency of the U.S. Department of Commerce;
is an organization that maintains current information about the state of the RBAC standard.
There have been many published papers explaining RBAC theory and practice.
Many variations of the RBAC standard are possible.
We decided to implement a simple version of RBAC.
The RBAC components we used are Roles, Operations, Objects, and Permissions.
Users are grouped together into Roles according to their job function.
Web-pages or screens are identified by their URL.
Screens are grouped together to form various Screen Object Groups.
Screen Object Groups are linked with Operations to create Permissions
Permissions are linked to User Roles.
Individual user information is stored in a LDAP file. All other RBAC data is stored in database tables.
We created a Helper class, UserAuthentication, that contained the authentication-related methods:
- build authentication data object
- retrieve authentication info from data object
- check for user in LDAP group
- get list of permissions for user
- check if user can access URL
Each time a user attempts to access a web-page\screen, the application calls a method in
UserAuthentication to determine if the user will be allowed access to the screen.
Maintaining the RBAC data, in the database, is accomplished thru a series of data entry screens.
Reports can be generated by the app to list all of the authentication info stored in the database.
When a new screen for the app is created, its URL is placed into a Screen Object Group.
New users of the app are placed into a User Group or Role.
New Roles are defined when needed.
New Screen Object Groups are created when a new Permission is required.
That's it. An all-Java implementation of a security industry standard, RBAC.
Done without the aid of third-party API's or products. All is safe and secure!