Re: Comments on Authz_Provider implementation (was: Re: svn commit: r351547 - in /httpd/h)

[Andreas Lindström <an...@gmail.com>]

> Require directives in the form of:
>
> require user joe bob jane
> require ldap-user jmanager
> require ldap-group bigboys
> require valid-user

I might have misunderstood something here, but this sounds like you
are proposing to move all directives into the specific files for the
authproviders. (This sounds like a good idea btw, as it most likely
will make the auth system easier to follow since all provider specific
routines are in the providers own file.)

If this is indeed what is intended, then the thing that should be
needed in mod_auth_basic and mod_auth_digest is some kind of wrapper
function that determines which provider that is active and then calls
the functions that are provider specific. Or possibly a function that
retrieves the result from the provider and then applies it in an
authtype specific way. The last one is probably the way to go (if
possible) as it will mean less authtype specific code in the provider
files.

However, if you want to run several auth providers you will probably
need some kind of Satisfy directive somewhere. An idea i previously
brought up was to place the directive in mod_authn_alias (that
probably should change name then, perhaps mod_authn_instance or
something) and use a syntax similar to "Satisfy ((instance1 &
instance2) | instance3) & !passwd " as this will add a great deal of
flexibility to the auth system.
If you leave mod_authn_alias to work as it does atm (as an optional
part) you could still declare the access checks directly in the
location that needs it, and you wouldnt need to use Satisfy for that
either if the design is made carefully to allow interswapping to occur
between the Satisfy directive in the alias module and the Require
directive from the provider files (or some check in basic, depending
on how you design it).

If the auth providers all handle their own verification of users based
on the require directives all this satisfy directive would need to do
is get the results from the auth providers own checks and run the
operations on it (if any). This would effectively make it possible to
use several different authproviders and declare them as instances
(pretty much the same syntax as mod_authn_alias uses now) and then use
the satisfy directive to just calculate the access rights.

Possibly these instances could be made specific to an authtype as
well, which would allow users of httpd to mix different auth types and
then only use the satisfy directive to check if the user has access or
not.

This would also make the config file less complicated to read as all
instances could be declared in one place and then referenced from the
Virtual Hosts or wherever you want to use them. It would also make it
possible to add a specific file or other provider with users you DONT
want to be able to log in, for example the passwd file where all
system wide users and others are entered, or possibly just a new
provider where you enters all the users that has been banned or
whatever.

Something like:

AuthBasicProvider ldap1 file1 sql1 passwd
AuthDigestProvider prov2
Satisfy ((ldap1 | file1 | sql1) | prov2) & !passwd

or:

AuthProvider ldap1 file1 sql1 passwd prov2
Satisfy ((ldap1 | file1 | sql1) | prov2) & !passwd

would be all thats needed to exist in the folder/file/location that
the access rules apply for. (Depending on if the auth type is defined
in the instances or if the modules for auth_basic/auth_digest will
define which instances are of which type.)

> How could we fit IP restrictions into this?
>
> require ip !192.168.0.0/24 10.0.1.5
>
> Possibly have deny/allow from semantics 'silently' convert into require
> directives?  Might be able to salvage backwards compat this way.

As for the ip access, it could be made into a pure bread auth module
if there was the will for it to happen as they would all handle their
own auth checks (or possibly a common auth function in some common lib
for all providers if theres alot of them that uses the same rules for
checking access. (this would make for less duplicate code, but
possibly make it less straightforward as well)

Another idea for ip access instances might be an idea to use Allow and
Deny, but in a different way:

Allow 10.0.1.5
Deny 192.168.0.0/24
Deny 100.0.0.0 255.255.255.255

or something like the above. This would allow one instance of the ip
access to include as many or as few of those directives as needed.
(And possibly also make it easier for users to understand the usage of
the ip access checker.)

The instances of providers would be handy here too as all provider
specific things would be gathered at one place, easier to get an
overlook over the auth rules and much less scrolling of potentially
(very!) long Virtual Host declarations (especially if you have some
rewrite rules in it). As for the ip access it would most likely need
the possibility of using several requires (or, see allow, deny above)
in one instance (shouldnt be a problem if the provider themselves
handle the authorization) or you could just use one require per
instance and then just use Satisfy to evaluate them as you want to.

"Satisfy (ip1 | ip2) & !ip3"

The silent conversion of allow and deny sounds like a good idea, at
least during a conversion period. Having both syntaxes active and
allowed at the same time shouldnt be much of a problem as long as an
example of the (soon to be) deprecated way and the new way are both
included in an example configuration file and the documentation.

Oh, as i havent had time to look into the auth system yet i dont have
that much of a clue as to how the current design is made, so much of
this might be insane ideas or whatever. If some of this seems
plausible to work and youd like to know more id be happy to draw up
some sort of a basic flow chart detailing as much of this idea as
possible.

All of this is so far only a basic idea of how it could be made to
work, for it to actually work some more time and thinking has to take
place. But as i havent heard any comments im not even sure if this is
plausible or not.

Long mail again... phew.

/ Andreas