Hi Michael --
> No, this is not the reason, why I want to split my application but
> still, I am not convinced that authorization belongs in Apache. Say I
> have an application with a company and branches. Now I want
> that a user
> is only allowed to run the runmodes with data of the brach the user
> belongs to.
> This info is within the application and Apache doesn't know anything
> about it -- at least if I don't want to duplicate my branch
> layout in a
> htgroups file or similar.
> Or if this case is still simple enough that with some tricks
> Apache can
> use the info in the database, what about special cases where
> a user is
> granted rights just for part of the info, say anything,
> except sallary?
> The 'knowledge' about the different roles of users is
> inherently within
> the application and I cannot see how Apache can do really flexible
> access restriction without being part of the application.
Good questions!
Let me start by separating Authentication from Authorization. The
former is the means of identifying the user who is logged in. The
latter is determining if that user is allowed to do a particular thing.
That being said, I think we can all agree that the means to determine
the identify of the user doesn't change at the application layer, and
may be entirely implemented in Apache. That leaves us with
Authorization. Authorization happens in many ways. There is general
authority, and there is the sort of fine-grained authority you refer to
in your message.
General authority might refer to whether a user is an anonymous public
user, a logged-in user, or an administrator. Tao Apache might suggest
that any request to the /admin/ directory require that the user is an
administrator, otherwise they are redirected to another page. Perhaps
only logged-in users (or administrators) may access the /membersonly/
directory.
This is the type of security for which Apache was designed. Apache's
whole security model is based on paths. Using the <Location> directives
(or .htaccess files) and "require group" directives you could easily
configure this type of general security. If you judiciously make use of
CGI-App instance scripts, as I described in my last message, you can
combine that with Apache's security philosophy to achieve probably 80%
of what you need.
That leaves the last 20% of the picture: Fine-grained authorization.
You describe situations where a user might not see a particular column,
or not be allowed to change a particular field. Once you get to the
point of contending with fine-grained security, you generally have to
add this code to your application layer.
Fortunately, you already know who the user is, and know that they are
allowed into the application. You only need to make very specific
tactical decisions. Your code can refer to the REMOTE_USER environment
variable with confidence that it is populated with a valid user. If you
have programmed your Apache Authorization module to do so, the user's
detailed authority settings may already be in the environment,
permitting you to know what fine-grained authority the user has without
the need to query a database again. All you have to do is:
show_delete_button() if ($ENV{USER_MAY_DELETE});
If you take the time, you could even centralize this logic in Perl
modules and in your HTML template layer. In Krang, for example, we use
a strict Model-View-Controller architecture. In the Model modules we
query the user's permissions to determine if they are permitted to edit
the particular object (e.g., a Story object in a particular category)
they are trying to edit. If the user attempts to save() or delete() an
object they are not permitted to edit, we throw an Exception::Class back
to the CGI-App ("Controller"), which is then caught and conveyed into
action: an alert to the user, entries in the security logs, etc.
Designing a system like this takes time, but it pays for itself ten-fold
in extensibility, reliability, and ease of future development.
HTH,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
