Question

I have an application that is coded using Flex 3 on UI side and java @ the service layer, along with BlazeDS. Now we need to authorize the users accessing the system based on the roles that are defined for them in the database, eg : say a user with role guest should not be able to access Admin tab on ui and also should not be able to do any operations other than viewing the data displayed on dashboard.Also the point to note here is that roles can be created dynamically by Super users from UI.

I came across this link which describes how to perform Role Based Authentication & Authorization

With this approach i need to define the roles in service-config.xml but since my roles are not pre-defined i cannot go with this.

Has anybody encountered a similar situation. Any pointers will be of great help.

Answer 1

Yes, I don’t like the service-config idea either, don’t blame you.

As far as the flex side, all you need to worry about is defining permissions, not roles or users of course.

Good form roles based security involves defining users, roles and permissions. You probably know this, but good to say it out loud anyway with the question.

• Users are assigned one or more roles
• Roles are assigned one or more permissions
• Permissions secure functionality

So, in your application, you define specific permissions – pieces of the app that are dependent on security – visible / invisible / can or cant execute, etc. The way I normally do this is with a string constant. So, in an order management situation, I might have CanCreateOrder, CanViewOrder, CanCancelOrder, CanFlagOrder.

On the server side, a role will be tied to those permissions. Lets say:

• Admin can do all
• CustomerService can do view, and flag
• Customer can do view

So on your server side, user A who is an admin, gets a list of all the permissions tied to the roles they are assigned, so the server sends back a string like this CanCreateOrder,CanViewOrder,CanCancelOrder,CanFlagOrder

Inside your application, when the user is authenticated and gets that list, its stored into a static global variable somewhere (or you .split() it into an array etc).

Then, when checking visibility or access to individual items, you simply check that array or string of values.

This offers a lot of flexibility as the items you are defining, most importantly, the permissions you’re basically hard coding – are specific to the functional code they exist in. Therefore, there isn’t a need to adjust them.

So, if you want to make customer service reps the ability to cancel orders later, you simply tie that permission to that role. Done. No code needs to be changed because the permission it simply tied to that functionality, not users, not roles.

I’ve done this in numerous applications, its a solid design. If you need permissions tied off other keys, that’s a mildly different story, but this is a good starting point regardless.

Make sense?

**Naturally you may encrypt the security exchange and send over SSL, securing that transaction is out of scope of the discussion 😉