> 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