RE: [WEB SECURITY] ACL for application

["Herbener, Martin - KETS Engineering and Management" <Martin.Herbener@xxxxxxxxxxxxxxxx>]

Ankur,

This may not fit in your overall ACL structure, but in a system I
developed we create specific identifiers for each action, determine the
list of identifiers/permissions for a user at logon, and use that list
of permissions to validate attempted actions throughout the life of the
logon session.   After the initial check for permissions we do not pay
any attention to the userid or roles for validating user actions (though
we keep using the userid for audit logging).   With this design it is
necessary to assign identifiers for every action that needs independent
control and to relate all identifiers to the superuser (or superuser
role) just like anyone else.  The advantage is that some changes to the
security structure (for instance, new roles) can be implemented without
any code changes, and others (new permissions/actions) require
relatively minor code changes; it is also possible to assign descriptive
labels to the various permissions which can enhance code readability.

Note that it may be necessary to check for appropriate permissions in a
couple different places in the code - usually before displaying the
link/button that initiates an action, and again before carrying out the
action, to protect against manual alteration of URLs, query strings,
etc.

Thanks

Martin

-----Original Message-----
From: Ankur Jindal [mailto:divinepresence@xxxxxxxxx] 
Sent: Monday, January 08, 2007 11:30 PM
To: websecurity@xxxxxxxxxxxxx
Subject: [WEB SECURITY] ACL for application

Hi all
How are application level ACL's usually implemented? Do you assume that
the users at higher levels, by default, have the same rights as the
users at lower levels (possibly even more) or does one need to
explicitly specify what each user can do?

We were preparing an ACL for a web application and were not sure if the
super admin should be given a specific functionality or not. The
application multiple user roles and service roles that perform data
actions. A couple of guys believed that since super admin is the highest
authority he can do whatever anyone else can do, and so, we don't need
to lay out all his rights completely. We just need to specify what he
can do that the others can't.

Another thought was that we write down clearly what everyone can do and
leave nothing to assumptions/beliefs.

Apologies if this was directed to the wrong list. Suggestions/links to
existing material are welcome.

Thanks
Ankur

------------------------------------------------------------------------
----
The Web Security Mailing List: 
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]


----------------------------------------------------------------------------
The Web Security Mailing List:
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]