[PROPOSAL][DISCUSSION] Applying 'AND/OR' logic to the authz providers...

[Brad Nicholes <bn...@novell.com>]

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

Re: [PROPOSAL][DISCUSSION] Applying 'AND/OR' logic to the authz providers...

[Graham Leggett <mi...@sharp.fm>]

Brad Nicholes wrote:

> 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).  

To cast a somewhat wider net over this.

The proxy framework's filter stack going to the backend seems to have 
similar requirements to "require" on the frontend.

In other words, just as you can say "require IP xx" on the frontend 
browser, you can also say "require IP yy" towards a backend server.

In a forward proxy situation you might use the reject directive as well: 
"reject host dodgy.site"

With the addition of fastcgi to the potential mod_proxy backends, proxy 
is becoming more and more "generic", where backend content providers are 
thought of as more "disconnected" than they are now.

It would be very cool if some of the authz providers could be used by 
the proxy as well, and we can get rid of the proxy specific Proxy* 
directives to do what require does.

Regards,
Graham
--

Re: [PROPOSAL][DISCUSSION] Applying 'AND/OR' logic to the authz providers...

[Brian Akins <br...@turner.com>]

Brad Nicholes wrote:

> 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 


I've seen some custom auth modules whose config looks pretty much like 
this pseudo code.  It's clumsy, but very powerful.


-- 
Brian Akins
Lead Systems Engineer
CNN Internet Technologies

Re: [PROPOSAL][DISCUSSION] Applying 'AND/OR' logic to the authz providers...

[Brad Nicholes <bn...@novell.com>]

>>> On 12/22/2005 at 2:18 am, in message
<20...@uk.tiscali.com>,
Brian Candler <B....@pobox.com> wrote:
> On Wed, Dec 21, 2005 at 01:16:53PM -0700, Brad Nicholes wrote:
>> <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
> 
> So if I write
> 
> <Directory /www/mydocs>
>   Authname...
>   ...
>   Require Group admins
>   Require ldap-group cn=mygroup,o=foo
> </Directory>
> 
> then from your example I think you're saying there is an implicit
> <RequireOne> around that, yes? If so, I think it would be better if
it were
> implicitly <RequireAll>. Otherwise it's easy to write an insecure
> configuration accidentally (you think you've written Require A *and*
B, when
> you've actually written Require A *or* B)

Yes, there is an implicit OR operation.  Mainly because that is how it
works today if you include multiple 'Require' directives.  So in order
to remain as backwards compatible as possible and not pull any
surprises, it should probably remain an OR operation.


> 
> What happens if I mix Require and Reject
> - within a <RequireAll> section
> - within a <RequireOne> section?
> 
> i.e. is 'Reject ...' exactly equivalent to 'Require Not ...', or is
it more
> complex than that?
> 
> Will there be <RejectOne> and <RejectAll> as well? That is, I think
you
> need NAND and NOR, or at least NOT around a group, to be able to
build any
> desired boolean combination.
> 

To be honest, I haven't given 'Reject' a lot of thought yet.  It was an
idea that was floated during our discussion at ApacheCon and I have been
focused more on the authz provider conversion and reworking the
'Require' directive.  My gut feel is that the 'Reject' directive will be
equivalent to 'Require not' as you suggested and that it will be folded
into the same <RequireAll>, <RequireOne> logic as the 'Require'
directive.  Basically with the new authz provider conversion, each
provider basically returns a boolean value, AUTHZ_GRANTED, AUTHZ_DENIED.
 I see reject doing the same thing based on what the arguments are. 
Therefore I believe that there wouldn't really be a need to implement a
<RejectOne>, <RejectAll>.  'Require' and 'Reject' should be able to be
mixed within the proposed configuration logic.


> Anyway, this framework does seem to be a lot more flexible and easier
to
> understand that the current one, especially if the 'Order allow,deny'
and
> 'Order deny,allow' stuff is eliminated :-)
> 
> Regards,
> 
> Brian.

:)

Brad

Re: [PROPOSAL][DISCUSSION] Applying 'AND/OR' logic to the authz providers...

[Brian Candler <B....@pobox.com>]

On Wed, Dec 21, 2005 at 01:16:53PM -0700, Brad Nicholes wrote:
> <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

So if I write

<Directory /www/mydocs>
  Authname...
  ...
  Require Group admins
  Require ldap-group cn=mygroup,o=foo
</Directory>

then from your example I think you're saying there is an implicit
<RequireOne> around that, yes? If so, I think it would be better if it were
implicitly <RequireAll>. Otherwise it's easy to write an insecure
configuration accidentally (you think you've written Require A *and* B, when
you've actually written Require A *or* B)

What happens if I mix Require and Reject
- within a <RequireAll> section
- within a <RequireOne> section?

i.e. is 'Reject ...' exactly equivalent to 'Require Not ...', or is it more
complex than that?

Will there be <RejectOne> and <RejectAll> as well? That is, I think you
need NAND and NOR, or at least NOT around a group, to be able to build any
desired boolean combination.

Anyway, this framework does seem to be a lot more flexible and easier to
understand that the current one, especially if the 'Order allow,deny' and
'Order deny,allow' stuff is eliminated :-)

Regards,

Brian.