Creating an Identity management framework
I ask - how many times have I written a login screen for any application? I have lost count. I did it when I started programming with the tools that support GUI. List includes - Foxbase, VB, Web Forms, and later Java Swing and now portal pages.
The options to store the credentials remain pretty much the same - RDBMS and a Directory server for more sophisticated implementations.
Frameworks like JAAS provide ability to plug-in implementations for login modules. Is it enough just to authenticate the user? Applications of course want to retrieve details of the logged-in user that includes the standard identifying information and minimal data that can relate a user with a business entity - one of importance in your domain model.
This trail is a thought process and implementation approach for an Identity management framework that may be extended to support authorization.
posted by Regu @ 2:18 PM
4 Comments:
Continuing with the idea of creating an Identity Management system, the first thing that came to my mind was identifying the key data elements in the system. I liked the Unix idea for this and came up with the following split:
Authentication elements
Authorization elements
Obviously the two need to tie together. The Authorization elements have behavior modelled in as well.
Authentication is fairly easy - you verify a given set of credentials against a user database. Dont be fooled to think database refers to a RDBMS only, it can be a Directory server or another user data store.
In the process, you take care of protocol, encryption e.t.c. to validate against the store. Plenty of frameworks and packages exist that allow you to easily integrate authentication.
Authorization is a challenge as it may be applied to a varied set of Objects that need to be secured, under varied rules(expressions) and for various users.
Now coming to the Authorization part.
Authorization is all about the following:
Object, Subject, Permission
Here Object can be any entity in your security framework. Take care to prevent proliferation of such object definitions - for e.g links to perform CRUD on an entity are NOT separate candidates for Object instances. They are in fact manifestations of the permissions on an Entity.
Subject refers to the Role that the currently logged in Principal is playing. Principal is nothing but the logged in user whose credentials you verified in the Authentication step. The Principal also contains the Subject reference/ID i.e the role code and is retrieved post login.
Permission specify permitted actions on an Object for a Subject. This completes the picture.
The last step would be to associate Principal(s) to Subject(s) aka User Provisioning.
You security framework is complete in terms of data setup i.e you are able to authenticate against a store, maintain association between a user and his Subject/role and also the mappings between Object, Subject and granted Permission(s).
During runtime, you would fetch the Subject instances provisioned for the logged in Principal and retrieve all granted Permission instances for all Object types. You r framework then identifies the most relevant Subject(and associated Permission instances) for the present authorization check and simply determines if the "intent" i.e the attempted action is "implied" by any of the granted permissions for e.g if the "intent" is "read", then a granted permission for "update" implies a "read".
Simple huh?
Post a Comment
<< Home