During ApacheCon we had a discussion about how to apply 'AND/OR' logic
to the Authz providers.  Those that were in attendance agreed that we
should eliminate the 'Satisfy all|any' directive in favor of something
that would handle not only host access control but authz access control
as well.  It was also suggested that the 'Require' directive could be
modified to handle all access control.  

Proposal for discussion:
   It was proposed that one way to handle host based as well as authz
access control was to first reimplement the directives 'Alllow', 'Deny'
and 'Order' as an authz provider (note: the authz-dev branch contains
the current effort to convert all authz handlers to providers much like
what was done for the authn providers).  By reimplementing these
directives as a provider, the same functionality could be achieved by
using the 'Require' directive (ie. Require IP 192.168.0.1 or Require
host mydomain.com).  It was also proposed that a 'Reject' directive also
be implemented to provide for the exception cases (ie. Reject IP
192.168.0.5 or Reject host yourdomain.com).  
   In addition to this, AND and OR logic would be introduced to authz in
the form of configuration blocks.  For example, the authz configuration
portion below would accomplish the following:

if ((user == "John) || 
   ((Group == "admin") && (ldap-group <stated-object> contains
auth'ed_user) &&
   ((ldap-attribute dept == "sales") || (file-group contains contains
auth'ed_user))))
then
   auth_granted
else
   auth_denied 

<Directory /www/mydocs>
   Authname ...
   AuthBasicProvider ...
   ...

  Require user John
  <RequireAll>
     Require Group admins
     Require ldap-group cn=mygroup,o=foo
     <RequireOne>
        Require ldap-attribute dept="sales"
        Require file-group
     </RequireOne>
  </RequireAll>
</Directory

   The current authz-dev branch contains code that implements the
<RequireAll>, <RequireOne> directive blocks as well as the conversion of
all of the authz handlers to providers (Although not fully tested).  It
also has an implementation of <RequireAlias> which functions much like
<AuthnProviderAlias> (although I haven't determined if the authz version
really provides much benefit).  It does not yet contain code for the
"Reject" directive or the re-implementation of "Allow, deny, order"
directives as authz handlers.  

Comments?

Brad

Reply via email to