The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Best Practice to implement Access Control List based security


We are trying to develop a security layer for a web application. Administrator can create Access Control Lists that can restrict a group or a user to access a page, functions(View, Add, Update, Delete something)... etc. Moreover the customer also wants to control the access rights for individual controls(textboxes, combo boxes or buttons) in the page. So, administrator can restrict groups' or users' access to the

1. pages
2. functions (ADD, EDIT, ... etc)
3. web controls

Do you know any "best prectice" or can you refer one to implement this structure efficiently?

Because in MY opinion, if we check those rights from database for EACH ACCESS to the page, the performance will decrease. There will be around 1000 user that will use this system. Moreover, there are many pages(around 80-90) and there will be at least 10 controls(textbox, button ...) in each page. 


Limbus Send private email
Monday, December 13, 2004
ACLs do suck some cycles.

But do you have a maxed-out database server already?

It might be that you can enforce your security app-server-side.  Consider fetching the effective permissions of the user once, and then using that directly in your page code.
i like i
Monday, December 13, 2004
From the 4 or 5 times I've had to build these, I'd recommend the following (your mileage may vary):

Implement the scheme in the database, but load user permissions ONCE on login. 

Store these permissions in the user session. 

Have methods to check a particular permission or role on the user.

Use this method anywhere you want to restrict accesss, e.g. "isUserInRole ("admin")"  or "userHasPermission("Edit")".

There are a few exceptions, namely, if the application itslef has implicit permissions, like "you can only delete something you created".  In this case, you'll still want to hide the permission scheme behind an interface or method, and you can add specific application business logic there (e.g., hasDeletePermission( Task t) would check the create user of the task and compare to the session user).

This stuff can get complicated, but if you stick with permissions, and hide it all behind a coherent set of methods, it will be easier to manage. 

Final tip - go ahead and use the database to manage access to data.  If a user can only see items he created, its OK to create a query that uses the USERID to filter out entries, etc.  Trying to add an application layer to do filtering is painful.
Monday, December 13, 2004
You might find this article handy. It's about using design patterns for application security, which might be helpful for you. I used this as a reference for a couple of classes in grad school.
Monday, December 13, 2004
I don't know about "best" practice, but I usually do the following:

[assuming asp/html front end, middle tier is COM+ DLLs]

create db tables with users, user types (admin etc), access rights, groups, etc.

create a login page for authentication (username & password). Do authentication in COM DLL.

If successful, create GUID and store in DB against this user. Also store in session cookie. Ignore any existing GUID*.

On every page (except login), perform authorisation by validating GUID in cookie against database. Needs to be fast.

Unless you're careful, you limit the user to one concurrent session only - not a serious issue, you just need to think about the design.
Can be insecure - may want to think about encryption or https
Make sure you use session cookies, not session variables - it won't be scaleable.

Speed has never been an issue - the system I'm currently working on has about 3000 users. A previous one a couple of years ago used the same design and had >40000 users (this is why you need to think about scaling!).

I've often thought about going the whole hog and shifting to using LSA to control everything. Maybe I'll do it sometime. This would be similar to Dave's system, where LSA authenticates, you cache the ACL, but you still have to implement per page authorisation.

The above solution is fairly cheap, fairly quick, fairly secure. It should be fine for most commercial intranet apps.
Justin Send private email
Monday, December 13, 2004
We are now do something like Dave recommend, have function like
"isUserInRole ("admin")"  or "userHasPermission("Edit")". For access control.

However, this approach make your component of business object depend of your access control implementation. Which, actually not a problem in most case.

If you facing a A better approach in my mind is create your custom java policy implementation, see:
or using AOP, either way can decouple your business logic with access control implementation, and make the access control implementation more configurable.
Carfield Yim Send private email
Monday, December 13, 2004
This might be outside the scope of whatever implementation you're considering or having to address but Zope has exactly this kind of extensible role model along for proxying when you have to lever access to places you wouldn't normally grant access to just to get off the ground.
Simon Lucy Send private email
Wednesday, December 22, 2004

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz