views:

24

answers:

1

Here's a question that I have been wrestling with for a while. We have a situation wherein we have a number of applications that we have created. These have grown organically over a period of time.

All of these applications have permissions code built into them that controls access to various parts of the application depending on whether the currently logged in user has the necessary permissions or not.

Alongside these applications is a utility application which allows an administrator to map users to permissions for all applications - the way it works is that every application has code which reads this external database of the said utility application to check if the currently logged in user has the necessary permission or not.

Now, the question is this. Should the user-permissions mapping information reside in and be owned by the applications themselves, or is it okay to have this information reside within an external entity/DB (as in this case the utility application's database).

Part of me thinks that application permissions are very specific to the application context itself, so shouldn't be separated from the application itself. But I am not sure.

Any comments?

+1  A: 

You should read up on federated identity, which is the new trend.

We have for over 10 years maintained a library we used across all applications which centralized user authentication and authorization. It is loosely coupled to AD and has centralized roles and rights that are managed by the user community based on business needs and not the network personnel.

Our design has afforded us the ability to embrace the new trends on federated identity practices along with claims based identity and simply update our library allowing all applications, some of which are written VB6 to use current security requirements.

Bill