Re: NCSA httpd

[Nathan Neulinger <nn...@umr.edu>]

>AuthUserFile /some/flat/file
>AuthDBMUserFile /some/dbm/file
...
>AuthUserFile /some/flat/file standard
>AuthUserFile /some/dbm/file dbm
...
>* Satisfy. There are enough patches floating around - can't we just
>  commit one already? (one that works, hopefully)

I really would like to see us come up with a better way of doing the
authentication control, instead of just adding more and more and more
directives for handling different authentication schemes. Everyone is doing
there own thing...

It would be MUCH better IMHO to come up with a good syntax that allows for
easily expanding the authentication capabilities, without cluttering the
directive name space.

I personally like the approach AIX 4.1 has taken for it's login authentication.

There is a file that you edit to change the system to use other
authentication mech, you can add what are called 'registries', and then
specify with a simply syntax what will let you in.

For example, to add AFS authentication to AIX 4.1 for logins, you specify
registry = DCE, and then specify the rule as "AFS OR AFS [UNAVAIL] AND
compat [SUCCESS]". Which basically says "let them in if AFS auth succeeds,
or if AFS is unavailable and regular authentication succeeds" (i think, not
100% sure... :)

I don't think we should use THAT syntax, but it would be nice to come up
with a good authentication/access control scheme that could be used for
more flexible control. Cause, right now, everyone is doing there own thing,
and it's not always clear how to add new auth methods.

For example, here is a possible scheme (just a quick idea)

<Method "local-users">
	# typical domain restrictions
	allow from my.domain
</Method>

<Method "remote-with-password">
	# typical auth stuff, but, would be good to come up with a standard
scheme
	# for these as well
	require valid-user
</Method>

#
# each method evaluates as a true/false value if the user matches the
particular method
# (i.e. is from my.domain for local-users, or is a valid-user for
"remote-with-password"
#

<AccessControl>
	default deny
	allow "local-users" or "remote-with-password"
</AccessControl>

or

<AccessDefault deny>
<AccessAllow>"local-users" or "remote-with-password"</AccessAllow>

the allow could be a fully parenthesized expression.

There would also be a <AccessDeny> and/or deny directive.

--------

For the auth modules themselves, would be nice to see if we could come up
with a standard set of directives that would cover what we needed by most
of the auth modules...

For example:

<Method "in-pass-file">
	AuthMethod internal
	AuthParam userfile "/my/pasword/file"
	AuthParam require valid-user
</Method>

The way I see it, and maybe this is totally unnaceptable, but, to me, there
should only be one authentication and access control API module, it should
handle all the require/satisfy/limiting by host/user/group/etc. In essence,
it should bring all the different auth schemes together.

I'm not sure whether the config file processing will support this sort of
thing, but if it does, this could be done as a new module... In essense, a
Authentication and Access Control SubAPI.

-- Nathan




-- Nathan

------------------------------------------------------------
Nathan Neulinger                  Univ. of Missouri - Rolla
EMail: nneul@umr.edu                  Computing Services
WWW: http://www.umr.edu/~nneul      SysAdmin: rollanet.org