You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Justin Erenkrantz <je...@apache.org> on 2002/08/27 06:18:16 UTC
authentication rewrite
I need to be able to get at the authentication backends to implement
some DAV enhancements - namely DAV has its own authentication model
(DAV ACL support). My idea would be to allow mod_dav to reuse the
aaa backends and just implement the client-facing bits there.
Therefore, I've begun to split up the authentication frontends
and backends. I've used the DAV philosophy by having providers
and registering them.
At this point, I have "file" and "dbm" backends which mod_auth_basic
and mod_auth_digest use. Hopefully, it should be trivial to add a
"ldap" backend. (mod_auth_basic is essentially mod_auth.)
As it is quite large (diffs are useless), you can find the code here:
http://www.apache.org/~jerenkrantz/new-aaa/
It should be a drop-in replacement to the modules/aaa dir. I've
got it handling Basic auth requests with both file and dbm backends.
I've yet to compile digest, but I should have changed the appropriate
bits to get it to cooperate. mod_auth_{dbm|file}.c does nothing
except provide the correct auth_provider structure so that the
authentication front-ends can use them.
Key files:
mod_auth.h - Header file
auth_provider.c - Similar to mod_dav's registration of providers
mod_auth_basic.c - Implementation of basic auth (rewritten)
mod_auth_digest.c - Implementation of digest auth
mod_auth_dbm.c - DBM provider
mod_auth_file.c - File provider
For a file-backed authentication, use:
AuthProvider file
AuthUserFile conf/dot-user
AuthType Basic
AuthName "Test Users"
For a DBM-backed authentication, use:
AuthProvider dbm
AuthDBMType default
AuthUserFile conf/dot-user-dbm dbm
AuthType Basic
AuthName "Test Users"
(Why AuthUserFile is a Take2 in mod_auth_dbm is unclear. That is
how it was before.)
I'd like to get this in the tree as I can't really start on the DAV
ACL stuff until aaa is properly split.
Yes, I realize this breaks configs, but this is the 'right' model to
move towards (and has been discussed here before, but no one has
sat down and implemented it). This has the large advantage of
getting rid of a lot of duplicate code. Hopefully, we could throw
out the code in server/protocol.c that deals with authentication!
Comments? Thoughts? -- justin
Re: Going to 2.1? was Re: authentication rewrite
Posted by Justin Erenkrantz <je...@apache.org>.
On Wed, Aug 28, 2002 at 02:56:10PM -0700, Greg Stein wrote:
> Well... this auth stuff doesn't even change the API. It provides a new
> opt-in arrangement for authenticating.
>
> (no new APIs for authz, tho; the code is just being refactored rather than
> new APIs to support that; the auth_checker hook is sufficient)
Can we agree on the name for the authn/authz split that Dirk has, do
the refactoring, and then come back later and add backwards compat
with directives?
My concern is that we may not be able to provide backwards compat
and then we effectively managed to hork 2.0. -- justin
Re: Going to 2.1? was Re: authentication rewrite
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Aug 28, 2002 at 11:15:14PM +0200, Dirk-Willem van Gulik wrote:
>
> > IMO, we shouldn't branch, and we shouldn't bother with a version bump. I
> > think we can ensure backwards compat for the directives, and only minor
> > changes in the modules which need to be LoadModule'd. That is quite fine for
>
> Aye - it is more the API than the directives.
Well... this auth stuff doesn't even change the API. It provides a new
opt-in arrangement for authenticating.
(no new APIs for authz, tho; the code is just being refactored rather than
new APIs to support that; the auth_checker hook is sufficient)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Going to 2.1? was Re: authentication rewrite
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> IMO, we shouldn't branch, and we shouldn't bother with a version bump. I
> think we can ensure backwards compat for the directives, and only minor
> changes in the modules which need to be LoadModule'd. That is quite fine for
Aye - it is more the API than the directives.
Dw
Re: Going to 2.1? was Re: authentication rewrite
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Aug 28, 2002 at 10:46:03PM +0200, Dirk-Willem van Gulik wrote:
>
> > branches in CVS are awful (perhaps not so with SVN though).
>
> Actually - the branching is trivial - it is the merging or the MFC which
> is a bit of a pain. I'd not worry about it. Take a look at the FreeBSD
> crowd who maintains several stable/release/current branches with
> relatively little overhead.
If anything, we'd branch 2.0 and keep the trunk as 2.1 development. As bugs
are fixed on the trunk, they'd be "ported" over to the 2.0 branch.
IMO, we shouldn't branch, and we shouldn't bother with a version bump. I
think we can ensure backwards compat for the directives, and only minor
changes in the modules which need to be LoadModule'd. That is quite fine for
a 2.0.x release.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Going to 2.1? was Re: authentication rewrite
Posted by Jim Jagielski <ji...@jaguNET.com>.
A few points/concerns:
At 1:15 PM -0700 8/28/02, Aaron Bannert wrote:
>On Wed, Aug 28, 2002 at 03:42:53PM -0400, Ryan Bloom wrote:
>> Just the same one I've had all along. Fix it in 2.0. If it is a major
>> config change, then we document it. We have made changes like this
>> before.
>
>I would consider this to be part of 2.0, even if we call it 2.1.
>Let me broaden this up a little with some general goals that I
>consider to be important. Let's take each of these goals on their
>own and consider their merit or feasibility:
>
>1) More frequent releases
Of course, not if it means each new release destroys some sort
of backwards compatibility. It would be painful, IMO, in this
particular case to hit someone who just made the transition to
2.0 to then be hit with a 2.1 upgrade.
We need to recall that in addition to a large developer community,
there's also a much larger *user* one :)
>2) We target the auth features for a release we will call 2.1
unless things are horribly wrong with the 2.0, which they aren't
*that* bad, then this would by personal choice. Again, this is mostly
with my "user community" hat on.
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson
Re: Going to 2.1? was Re: authentication rewrite
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Aug 28, 2002 at 03:42:53PM -0400, Ryan Bloom wrote:
> Just the same one I've had all along. Fix it in 2.0. If it is a major
> config change, then we document it. We have made changes like this
> before.
I would consider this to be part of 2.0, even if we call it 2.1.
Let me broaden this up a little with some general goals that I
consider to be important. Let's take each of these goals on their
own and consider their merit or feasibility:
1) More frequent releases
- By making releases more often, we can help foster a healthy
testing community that can provide valuable feedback and
eventually improve the quality of the server. We don't need
to restrict ourselves to the ASF-cabal-approved official release,
nor the opposite extreme nightly snapshots (which connote no
amount of quality, stability, or features).
2) Well-defined features
- There is sort of a catch-22 here. Our volunteer work on features within
the server can not be constrained by a deadline, but it would be good
to identify major and minor changes and feature additions and give them
an appropriately incremented revision number. Later our users can
go into our documentation and find out, for example, what it means
when 2.1 has a new authentication framework. (Remember, revision numbers
are free, but providing clear and precise information to our users
comes at a steep price.)
3) Fostering a healthy testing community
- This is one area that I believe the HTTP Server Project has failed
miserably compared to other projects of equal popularity, at least
as long as I have been involved. I also believe this is a direct
result of the failure to identify the above problems. People want
to play with new features, but they need to know what those features
are before they start to play. We also have to give them something
to play with, which means rapid-fire releases with well-documented
features.
In the short term I propose the following:
1) We start work on a new auth framework in whatever way is most comfortable
for those who will work on it -- either in the 2.0 tree or in a branch
or whatever. (Ideally we don't break the config on this rather large
piece without at least a minor-revision bump.)
2) We target the auth features for a release we will call 2.1
3) We maintain this pace for any new features that arise, and decide
on a per-feature bases whether it fits in the current minor revision,
in a new minor-revision, or in a new major-revision.
-aaron
Re: Going to 2.1? was Re: authentication rewrite
Posted by rb...@apache.org.
On Wed, 28 Aug 2002, Aaron Bannert wrote:
> On Wed, Aug 28, 2002 at 12:25:36PM -0700, Justin Erenkrantz wrote:
> > branches in CVS are awful (perhaps not so with SVN though).
>
> I have only heard anecdotal evidence for this, but have actually
> used cvs branches on other large and very successful projects
> before. (*cough* PHP! *ahem*). I'd rather see a cvs branch than
> a whole new copy of the repository. We can wait until the 3.0
> cycle to switch to SVN or start a new repository if we want.
>
> > Not to mention our repository is "httpd-2.0" - I don't think it makes
> > sense to have a 2.1 in there.
> >
> > I'm not entirely sold on splitting off to a 2.1 yet, but I think we
> > now have something where it is worth discussing it. -- justin
>
> I'd really like to see us start attacking smaller-grain problems
> and releasing those features more often, rather than lining up years
> and years of "ooh me too and this too" until we've got bugs coming
> out of our ears and nothing stable out the door for our users and
> testers. IMHO, a new auth framework is a *perfect* target for the
> next milestone, and it makes sense to call it 2.1.
>
> Any other opinions?
Just the same one I've had all along. Fix it in 2.0. If it is a major
config change, then we document it. We have made changes like this
before.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
Re: Going to 2.1? was Re: authentication rewrite
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Aug 28, 2002 at 12:25:36PM -0700, Justin Erenkrantz wrote:
> branches in CVS are awful (perhaps not so with SVN though).
I have only heard anecdotal evidence for this, but have actually
used cvs branches on other large and very successful projects
before. (*cough* PHP! *ahem*). I'd rather see a cvs branch than
a whole new copy of the repository. We can wait until the 3.0
cycle to switch to SVN or start a new repository if we want.
> Not to mention our repository is "httpd-2.0" - I don't think it makes
> sense to have a 2.1 in there.
>
> I'm not entirely sold on splitting off to a 2.1 yet, but I think we
> now have something where it is worth discussing it. -- justin
I'd really like to see us start attacking smaller-grain problems
and releasing those features more often, rather than lining up years
and years of "ooh me too and this too" until we've got bugs coming
out of our ears and nothing stable out the door for our users and
testers. IMHO, a new auth framework is a *perfect* target for the
next milestone, and it makes sense to call it 2.1.
Any other opinions?
-aaron
Re: Going to 2.1? was Re: authentication rewrite
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> branches in CVS are awful (perhaps not so with SVN though).
Actually - the branching is trivial - it is the merging or the MFC which
is a bit of a pain. I'd not worry about it. Take a look at the FreeBSD
crowd who maintains several stable/release/current branches with
relatively little overhead.
Dw
RE: Going to 2.1? was Re: authentication rewrite
Posted by "John K. Sterling" <jo...@sterls.com>.
If we do wait for 2.1, it would give us the opportunity to collaborate and
make this really clean......you could just create a repository for the new
auth modules (even on sourceforge or something) - assuming not too many
core changes are required.
sterling
>-- Original Message --
>Reply-To: dev@httpd.apache.org
>Date: Wed, 28 Aug 2002 12:25:36 -0700
>From: Justin Erenkrantz <je...@apache.org>
>To: Aaron Bannert <aa...@clove.org>, dev@httpd.apache.org
>Subject: Going to 2.1? was Re: authentication rewrite
>
>
>On Wed, Aug 28, 2002 at 11:57:42AM -0700, Aaron Bannert wrote:
>> This is a big enough of a change that I would be willing to allow
>> for a branch to 2.1 at this point (not a full new repository, just
>> a cvs branch) so that you and others who are interested can work on
>> the auth stuff, and so we don't break the configs in 2.0's auth.
>
>branches in CVS are awful (perhaps not so with SVN though).
>
>Not to mention our repository is "httpd-2.0" - I don't think it makes
>sense to have a 2.1 in there.
>
>I'm not entirely sold on splitting off to a 2.1 yet, but I think we
>now have something where it is worth discussing it. -- justin
Going to 2.1? was Re: authentication rewrite
Posted by Justin Erenkrantz <je...@apache.org>.
On Wed, Aug 28, 2002 at 11:57:42AM -0700, Aaron Bannert wrote:
> This is a big enough of a change that I would be willing to allow
> for a branch to 2.1 at this point (not a full new repository, just
> a cvs branch) so that you and others who are interested can work on
> the auth stuff, and so we don't break the configs in 2.0's auth.
branches in CVS are awful (perhaps not so with SVN though).
Not to mention our repository is "httpd-2.0" - I don't think it makes
sense to have a 2.1 in there.
I'm not entirely sold on splitting off to a 2.1 yet, but I think we
now have something where it is worth discussing it. -- justin
Re: authentication rewrite
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Aug 28, 2002 at 11:37:03AM -0700, Justin Erenkrantz wrote:
> We could also work towards fixing up other stuff in 2.1 (say hi to
> ap_resource_t). But, the item we've got on the plate here is an
> aaa rewrite.
>
> So, my take is either break configs in 2.0 or move to 2.1.
> Maintaining backwards compat just doesn't sound healthy. -- justin
This is a big enough of a change that I would be willing to allow
for a branch to 2.1 at this point (not a full new repository, just
a cvs branch) so that you and others who are interested can work on
the auth stuff, and so we don't break the configs in 2.0's auth.
-aaron
Re: authentication rewrite
Posted by Justin Erenkrantz <je...@apache.org>.
On Wed, Aug 28, 2002 at 10:42:01AM -0700, Aaron Bannert wrote:
> On Wed, Aug 28, 2002 at 04:50:52AM -0700, Justin Erenkrantz wrote:
> > I'm beginning to think that we're going to lose all hope of
> > maintaining backwards compat with the current 2.0 auth. But, as
> > Greg said, I definitely think that we're going is going to be an
> > awfully nice place. -- justin
>
> If this is enough of a change, why don't we call it the main feature
> of 2.1 and start working toward that? I'd really like to see us identify
> features like this that are smaller step changes and then do dot
> releases on those features. Makes it much easier on our users to
> find out what has changed, too.
Heh. Someone finally bit. I was wondering how long it would take
before someone brought up 2.1. =)
We could also work towards fixing up other stuff in 2.1 (say hi to
ap_resource_t). But, the item we've got on the plate here is an
aaa rewrite.
So, my take is either break configs in 2.0 or move to 2.1.
Maintaining backwards compat just doesn't sound healthy. -- justin
Re: authentication rewrite
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Aug 28, 2002 at 04:50:52AM -0700, Justin Erenkrantz wrote:
> I'm beginning to think that we're going to lose all hope of
> maintaining backwards compat with the current 2.0 auth. But, as
> Greg said, I definitely think that we're going is going to be an
> awfully nice place. -- justin
If this is enough of a change, why don't we call it the main feature
of 2.1 and start working toward that? I'd really like to see us identify
features like this that are smaller step changes and then do dot
releases on those features. Makes it much easier on our users to
find out what has changed, too.
-aaron
Re: authentication rewrite
Posted by jo...@sterls.com.
Hi -
>-- Original Message --
>Reply-To: dev@httpd.apache.org
>Date: Wed, 28 Aug 2002 04:50:52 -0700
>From: Justin Erenkrantz <je...@apache.org>
>To: dev@httpd.apache.org
>Subject: Re: authentication rewrite
>I'm not sure I like mod_authz_dbm.c either. Hmm. But, frankly, I
>just can't come up with something better. Anyone else?
mod_authz_dbm doesn't seem so bad to me.
by the way: I worked out the beginnings of the provider stack (AddAuthProvider)
last night. I'll wait for stuff to start getting committed, then I'll put
together a patch against that.
sterling
Re: authentication rewrite
Posted by Justin Erenkrantz <je...@apache.org>.
On Wed, Aug 28, 2002 at 11:19:43AM +0200, Dirk-Willem van Gulik wrote:
>
> > I don't want to add it in and then have to back it out because people
> > didn't realize that it is going to hose existing configs.
>
> Justin - you want me to commit this
> http://www.webweaving.org/~dirkx/aaa.tgz simplication first ? I've held
> back as we where releasing .40. That should make your live a hell of a lot
> simpler.
Yeah, I think we do want to split out authn and authz first.
At this point, my preferred ordering is:
1) split out authn/authz
2) add a generic ap_provider_* mechanism
(avoids duplication with dav and auth)
3) add provider model to authn
My one concern with your approach is that the naming of
mod_access_dbm.c is awful. The code looks like it has the right
concept though.
I'm not sure I like mod_authz_dbm.c either. Hmm. But, frankly, I
just can't come up with something better. Anyone else?
I'm beginning to think that we're going to lose all hope of
maintaining backwards compat with the current 2.0 auth. But, as
Greg said, I definitely think that we're going is going to be an
awfully nice place. -- justin
Re: authentication rewrite
Posted by Justin Erenkrantz <je...@apache.org>.
On Wed, Aug 28, 2002 at 11:19:43AM +0200, Dirk-Willem van Gulik wrote:
>
> > I don't want to add it in and then have to back it out because people
> > didn't realize that it is going to hose existing configs.
>
> Justin - you want me to commit this
> http://www.webweaving.org/~dirkx/aaa.tgz simplication first ? I've held
> back as we where releasing .40. That should make your live a hell of a lot
> simpler.
Honestly, I haven't taken a look at it yet.
Pulling it up now. -- justin
Re: authentication rewrite
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> Hmm. Crap. I'm looking at mod_auth_dbm.c. Damn... it appears that *both*
> mod_auth and mod_auth_dbm define the AuthUserFile and AuthGroupFile
> directives.
Yes - this is the main reason I started the www.apache.org/~dirkx/aaa.tgz
simplification.
> Beats the crap outta me how that happens to work.
Because they overload - Whick makes Johns point very valid.
Dw.
Re: authentication rewrite
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Aug 28, 2002 at 01:59:29AM -0700, Justin Erenkrantz wrote:
> On Tue, Aug 27, 2002 at 05:25:25PM -0700, Greg Stein wrote:
> > It would seem that changes to the directives would be easy, and we could
> > also deprecate older directives. In all cases, we'd change our .conf files
> > and the doc, issue warnings for old usage, and then just "wait a while"
> > before removing old support.
>
> The real problem is with mod_auth_dbm. Part of the problem is that
> mod_auth_dbm is dependent on the new mod_auth_basic. I guess we
> could force mod_auth_dbm to build mod_auth_basic via config.m4 magic.
> (mod_auth would be removed entirely, so that might be iffy too.)
Yes, the build part could be done relatively easily. Tossing mod_auth
wouldn't be too bad, as that would affect just one line in a user's config,
and the "failure mode" would be obvious. The server would hit the LoadModule
and punt right there. Delete that line and off you go...
> Yet, I'm not clear how we could trick mod_auth_basic to use DBM
> unless they add "AuthProvider dbm" to mimic the old mod_auth_dbm
> code. (The catch is that mod_auth_basic should use 'file' as the
> default provider to mimic the no longer present mod_auth.)
Hmm. Crap. I'm looking at mod_auth_dbm.c. Damn... it appears that *both*
mod_auth and mod_auth_dbm define the AuthUserFile and AuthGroupFile
directives. Beats the crap outta me how that happens to work.
And then it would appear that both of them run. And the ordering is
arbitrary between the two (both are MIDDLE hooks). If a file and a dbm
happen to define the same user, then it is "random" which you'll auth
against (in terms of the password).
It would seem that the default is to run both, unless somebody sets an
"authoritative" flag. In that case, you run just one.
> Hmm. One thought would be to implement the multiple provider
> scheme John mentioned and always do file/dbm unless said so. But,
> ick, that might catch people by surprise and I'm not sure if that
> is really possible as mod_auth_dbm and mod_auth used to share the
> same config syntax (ick!), so I'm unclear what would happen when
> both would try to interpret things. Ick, ick, ick.
>
> Thoughts? -- justin
I think it might be doable. Note that the "AuthAuthoritative" and
"AuthDBMAuthoritative" would be deprecated. To make something
"authoritative", you just don't include the other providers:
AuthProvider file dbm # file first, then dbm
AuthProvider file # file is "authoritative"
AuthProvider dbm # dbm is "authoritative"
The answer seems to be "in there somewhere". The problem is untangling the
mess that we have now. Thankfully, post-entanglement will be a nice place to
be :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: authentication rewrite
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Aug 27, 2002 at 05:25:25PM -0700, Greg Stein wrote:
> It would seem that changes to the directives would be easy, and we could
> also deprecate older directives. In all cases, we'd change our .conf files
> and the doc, issue warnings for old usage, and then just "wait a while"
> before removing old support.
The real problem is with mod_auth_dbm. Part of the problem is that
mod_auth_dbm is dependent on the new mod_auth_basic. I guess we
could force mod_auth_dbm to build mod_auth_basic via config.m4 magic.
(mod_auth would be removed entirely, so that might be iffy too.)
Yet, I'm not clear how we could trick mod_auth_basic to use DBM
unless they add "AuthProvider dbm" to mimic the old mod_auth_dbm
code. (The catch is that mod_auth_basic should use 'file' as the
default provider to mimic the no longer present mod_auth.)
Hmm. One thought would be to implement the multiple provider
scheme John mentioned and always do file/dbm unless said so. But,
ick, that might catch people by surprise and I'm not sure if that
is really possible as mod_auth_dbm and mod_auth used to share the
same config syntax (ick!), so I'm unclear what would happen when
both would try to interpret things. Ick, ick, ick.
Thoughts? -- justin
Re: authentication rewrite
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Aug 27, 2002 at 05:02:19PM -0700, Justin Erenkrantz wrote:
> On Tue, Aug 27, 2002 at 05:03:11PM -0700, Greg Stein wrote:
> > Put it in there, then :-)
> >
> > I haven't really seen any objects so far. And hey... this *is* version
> > control. It can always be backed out :-)
>
> I don't want to add it in and then have to back it out because people
> didn't realize that it is going to hose existing configs.
>
> If we're cool with that, then fine. -- justin
Oh yah... the config thing. There isn't a way to keep existing configs? To
simply deprecate older configurations?
Is the problem that older configs need to add a new directive? And if so,
then could we add it automagically? Yes, this would hard-code a dependency
between two modules, but that would be better than a broken config. And we
can take out the auto-config at some future point.
It would seem that changes to the directives would be easy, and we could
also deprecate older directives. In all cases, we'd change our .conf files
and the doc, issue warnings for old usage, and then just "wait a while"
before removing old support.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: authentication rewrite
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> I don't want to add it in and then have to back it out because people
> didn't realize that it is going to hose existing configs.
Justin - you want me to commit this
http://www.webweaving.org/~dirkx/aaa.tgz simplication first ? I've held
back as we where releasing .40. That should make your live a hell of a lot
simpler.
DW
Re: authentication rewrite
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Aug 27, 2002 at 05:03:11PM -0700, Greg Stein wrote:
> Put it in there, then :-)
>
> I haven't really seen any objects so far. And hey... this *is* version
> control. It can always be backed out :-)
I don't want to add it in and then have to back it out because people
didn't realize that it is going to hose existing configs.
If we're cool with that, then fine. -- justin
Re: authentication rewrite
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Aug 27, 2002 at 03:27:10PM -0700, Justin Erenkrantz wrote:
> On Tue, Aug 27, 2002 at 02:43:24PM -0400, john@sterls.com wrote:
> > I could send a patch to your current code if that would be clearer - its
> > really pretty simple, but would allow the backends to get at least a little
> > more powerful (and would solve the ldap_prop case i illustrated above
>
> Definitely. =)
>
> I want to get this into the repository, so we can start fixing it.
> I don't want it to be developed outside of the tree. -- justin
Put it in there, then :-)
I haven't really seen any objects so far. And hey... this *is* version
control. It can always be backed out :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: authentication rewrite
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Aug 27, 2002 at 02:43:24PM -0400, john@sterls.com wrote:
> I could send a patch to your current code if that would be clearer - its
> really pretty simple, but would allow the backends to get at least a little
> more powerful (and would solve the ldap_prop case i illustrated above
Definitely. =)
I want to get this into the repository, so we can start fixing it.
I don't want it to be developed outside of the tree. -- justin
Re: authentication rewrite
Posted by jo...@sterls.com.
Hi -
>-- Original Message --
>Reply-To: dev@httpd.apache.org
>Date: Tue, 27 Aug 2002 09:51:09 -0700
>From: Justin Erenkrantz <je...@apache.org>
>To: dev@httpd.apache.org
>Subject: Re: authentication rewrite
>
>
>On Tue, Aug 27, 2002 at 10:12:43AM -0400, john@sterls.com wrote:
>Without seeing use cases, it's hard to know what people want. For
>now, I can only go off of what we have now.
>
>(I'm hoping that people who write third-party auth engines speak
>up now and point out how this API could make it better for them if
>it only did XYZ.)
welp, that is why i spoke up i suppose. A use case is the desire for ldap
auth to allow for property requirements. e.g. Require ldap_prop department=engineering
for example (that's hypothetical syntax). You would need to add a new function
to the callback structure validate_property(name, value) or something.
While this would be easy to add (and would be reusable by various database
auth modules) - it is just an example of many possible requirements.
you could add another callback function to your backend structure - this
function would be register_requirement_handler(requirement_name, function).
In your switch statement "valid-user", "user", "group", it could fall through
by looking for a handler that has been registered for that requirement.
That handler would simply be passed the rest of the requirement string
- and would return 0,1.
I could send a patch to your current code if that would be clearer - its
really pretty simple, but would allow the backends to get at least a little
more powerful (and would solve the ldap_prop case i illustrated above
sterling
Re: authentication rewrite
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> Yeah, you hit the problem with stacking - authoritative. I'm not
> sure how useful having multiple backends could be. I'd almost
> suggest that something like a PAM backend would be much better and
> allows a fairly standard configuration. (I know Dirk has a PAM
It is integrated into the PAM project at the sourceforge. I've worked with
the author(s) to give it an ASF style license - and they'd be more than
happy to share/donate the module to the ASF.
Issues with respect to Maintenace and Community would of course still be
there and I've not looked into that.
> module somewhere.) That removes the stacking component entirely if
> we supported PAM.
Actually - because of PAM, especially remote PAM into radius or tacacs,
stacking at the very least a file based 'backup' auth provider in the tree
(preferably independend of PAM - which can have finicky failure mode) is
invaluable in operational environments in my experience.
Dw
Re: authentication rewrite
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Aug 27, 2002 at 10:12:43AM -0400, john@sterls.com wrote:
> than the current AAA modules. In a 'require group' world, it is very nice
> to abstract this stuff out so backends can be re-used, and apache specific
> logic can be centralized - as you have proposed. But it will be harder
> to plug in backends that try to do more with requirements (of which there
> really aren't many)- which is probably fine.
Without seeing use cases, it's hard to know what people want. For
now, I can only go off of what we have now.
(I'm hoping that people who write third-party auth engines speak
up now and point out how this API could make it better for them if
it only did XYZ.)
> 1) It looks like the 'AuthProvider' does not allow you to stack auth handlers.
> I would be cool (if not critical :) if it was more of an AddAuthProvider
> - then the basic auth handler loops through all providers that are added.
> This way you could configure ldap and anon for a given location.
>
> 2) If you do allow stacking of providers like this, you need to also provide
> the ability to specify which one is authoritative (if any).
Yeah, you hit the problem with stacking - authoritative. I'm not
sure how useful having multiple backends could be. I'd almost
suggest that something like a PAM backend would be much better and
allows a fairly standard configuration. (I know Dirk has a PAM
module somewhere.) That removes the stacking component entirely if
we supported PAM.
But, yeah, I think we could implement multiple providers ourselves
if we wanted to.
> 3) maybe i'm missing something, but why did you rewrite ap_note_basic_auth_failure
> and ap_get_basic_auth? assuming there was a reason, maybe a comment in
> the code would help clarify it.
I want to toss ap_note_basic_auth_failure and ap_get_basic_auth.
That code doesn't belong in the server/protocol.c. Ideally, any
modules that were using these functions could just implement a
backend module. But, I don't think we want to have those exported
going forward - the only reason they are exported is because our API
sucked. -- justin
Re: authentication rewrite
Posted by Greg Stein <gs...@lyra.org>.
a big +1...
On Mon, Aug 26, 2002 at 11:44:32PM -0700, Justin Erenkrantz wrote:
>...
> My point is that I need to add another front end authentication
> module (namely within mod_dav). I think it'd be pointless to
> duplicate all of the backend work done in mod_auth* so that
> mod_dav can authenticate users.
Eh? I thought you wanted *access* to the user information, not to perform
authentication.
And/or maybe you need the data for authorization?
> The current authentication API
> can't work as it combines the front and back-ends. The answer we
> give to people is, "cut-and-paste." Ick. Therefore, yes, I think
> we have to introduce another level as what we have now is
> insufficient.
Absolutely. I recall Ken and I talking about this kind of separation over
three years ago.
>...
> And, it doesn't mandate that third-party modules have to move to this
> scheme - it's opt-in.
Yup. Unless you kill the helper functions from server/protocol.c. :-)
>...
> Of course, I would expect the API to become better as we play with it
> more and determine what is missing. However, this API is currently
> sufficient for the two providers that are already included - enough
> so that I think future work warrants inclusion in the tree. As we
Absolutely. You have to start somewhere. If you want for perfection, then
you'll never get anything done.
Some random nits/comments about the code itself:
* get_user_groups() should return a hash rather than a table, right? Or do
you truly need the case insensitively? If so, then couldn't you mandate
the provider insert lower-cased values, and then you can look them up that
way?
* need the various guards/wrappers in mod_auth.h
* some of your files refer to "Portions of this software based on..." I
seriously doubt that is true for your new files :-) [altho it probably
*is* true for mod_auth derivatives]
* mod_auth_file/dbm.c: the module rec has a comment about "command
apr_table_t"... it isn't a apr_table_t. some old search/replace comment?
* mod_auth_dbm.c: obsolete comment at the top (between license and first
#include line)
* mod_auth_file.c: constify the values in auth_file_config_rec
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: authentication rewrite
Posted by Graham Leggett <mi...@sharp.fm>.
Justin Erenkrantz wrote:
> Ideally, you could use the LDAP filters that most PAM implementations
> use, but definitely allow the user to tweak them. I'd like to get
> mod_auth_ldap ported to this, and if we move towards a provider-based
> system, I think mod_auth_ldap should be moved back into the core.
> (Namely because that's the preferred auth for DAV ACL support as it
> is hierarchical.)
I want to see auth_ldap moved into experimental so that it is included
in any work done on overhauling the auth stuff.
Currently the code is receiving minimal exposure where it is.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm
"There's a moon
over Bourbon Street
tonight..."
Re: authentication rewrite
Posted by jo...@sterls.com.
Hi Justin -
>-- Original Message --
>Reply-To: dev@httpd.apache.org
>Date: Mon, 26 Aug 2002 23:44:32 -0700
>From: Justin Erenkrantz <je...@apache.org>
>To: dev@httpd.apache.org
>Subject: Re: authentication rewrite
>
>My point is that I need to add another front end authentication
>module (namely within mod_dav). I think it'd be pointless to
>duplicate all of the backend work done in mod_auth* so that
>mod_dav can authenticate users. The current authentication API
>can't work as it combines the front and back-ends. The answer we
>give to people is, "cut-and-paste." Ick. Therefore, yes, I think
>we have to introduce another level as what we have now is
>insufficient.
I understand your point, and I think its a good one. I just wanted to raise
a concern (which I still think is important to think about). about a year
and a half ago I abstracted the auth stuff in a similar way - In my case,
however, I wanted the back ends to have much richer authorization functionality
than the current AAA modules. In a 'require group' world, it is very nice
to abstract this stuff out so backends can be re-used, and apache specific
logic can be centralized - as you have proposed. But it will be harder
to plug in backends that try to do more with requirements (of which there
really aren't many)- which is probably fine.
>In my vision, the LDAP module would have its own directives/options
>to specify what it returns. So, I don't think this is a big concern.
>
>I'd imagine something like:
>
>AuthProvider ldap
>AuthLDAPServer ldap.example.com
>AuthLDAPBase o=example.com
>AuthLDAPUserSearch (username=%s)
>AuthLDAPGroupSearch (groupmember=%s)
here's a couple of comments on the implementation:
1) It looks like the 'AuthProvider' does not allow you to stack auth handlers.
I would be cool (if not critical :) if it was more of an AddAuthProvider
- then the basic auth handler loops through all providers that are added.
This way you could configure ldap and anon for a given location.
2) If you do allow stacking of providers like this, you need to also provide
the ability to specify which one is authoritative (if any).
3) maybe i'm missing something, but why did you rewrite ap_note_basic_auth_failure
and ap_get_basic_auth? assuming there was a reason, maybe a comment in
the code would help clarify it.
hope this helps.
sterling
Re: authentication rewrite
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Aug 27, 2002 at 12:46:17AM -0400, John K. Sterling wrote:
> Hmm -
>
> My biggest concern here is that you are now adding another layer of
> abstraction on the apache api. It seems nice in theory, but it is not
> very extensible. If this were to be going in only for the simple auth
> modules we currently support (which are almost never changed or
> augmented) i suppose it wouldn't be a big deal. The ldap module,
My point is that I need to add another front end authentication
module (namely within mod_dav). I think it'd be pointless to
duplicate all of the backend work done in mod_auth* so that
mod_dav can authenticate users. The current authentication API
can't work as it combines the front and back-ends. The answer we
give to people is, "cut-and-paste." Ick. Therefore, yes, I think
we have to introduce another level as what we have now is
insufficient.
Currently, most of the code in mod_auth_dbm is just a duplication of
mod_auth. mod_auth_digest does not support anything other than flat
files. This would remove code duplication and add features where the
code wasn't duplicated. I see this as a win just from porting the
'simple' modules over to a scheme like this. Nevermind mod_dav.
And, it doesn't mandate that third-party modules have to move to this
scheme - it's opt-in.
> however, may 1: not want to return all groups a user is in (as opposed
> to letting the directory perform a search for us) and 2: may want more
> complex control of requirements (e.g. property limitations etc.) - I
> find it clean in theory, but ironically cumbersome in practice to try
> to simplify the auth api like this -
In my vision, the LDAP module would have its own directives/options
to specify what it returns. So, I don't think this is a big concern.
I'd imagine something like:
AuthProvider ldap
AuthLDAPServer ldap.example.com
AuthLDAPBase o=example.com
AuthLDAPUserSearch (username=%s)
AuthLDAPGroupSearch (groupmember=%s)
Ideally, you could use the LDAP filters that most PAM implementations
use, but definitely allow the user to tweak them. I'd like to get
mod_auth_ldap ported to this, and if we move towards a provider-based
system, I think mod_auth_ldap should be moved back into the core.
(Namely because that's the preferred auth for DAV ACL support as it
is hierarchical.)
Of course, I would expect the API to become better as we play with it
more and determine what is missing. However, this API is currently
sufficient for the two providers that are already included - enough
so that I think future work warrants inclusion in the tree. As we
add mod_dav support, we may need more to add more functions, but the
point is that this API is extensible.
> maybe abstracting out some of the logic into re-usable libraries would
> work, but layering callback structures like this is IMO not the way to
> go.
My point is that we need to 'layer callback structures' like this
to allow other modules to reuse the authentication backends.
Currently, our authentication design doesn't allow for reuse.
If we were to code it up as 're-usable libraries', we wouldn't allow
them to define their own directive syntax like my proposed solution
would. So, I think there is a benefit for making these providers
modules in their own right - they just don't implement the access
hooks. But, by being modules, it allows them flexibility in how
they are configured that they wouldn't ordinarily have. -- justin
Re: authentication rewrite
Posted by "John K. Sterling" <jo...@sterls.com>.
Hmm -
My biggest concern here is that you are now adding another layer of
abstraction on the apache api. It seems nice in theory, but it is not
very extensible. If this were to be going in only for the simple auth
modules we currently support (which are almost never changed or
augmented) i suppose it wouldn't be a big deal. The ldap module,
however, may 1: not want to return all groups a user is in (as opposed
to letting the directory perform a search for us) and 2: may want more
complex control of requirements (e.g. property limitations etc.) - I
find it clean in theory, but ironically cumbersome in practice to try
to simplify the auth api like this -
maybe abstracting out some of the logic into re-usable libraries would
work, but layering callback structures like this is IMO not the way to
go.
sterling
On Tuesday, August 27, 2002, at 12:18 AM, Justin Erenkrantz wrote:
> I need to be able to get at the authentication backends to implement
> some DAV enhancements - namely DAV has its own authentication model
> (DAV ACL support). My idea would be to allow mod_dav to reuse the
> aaa backends and just implement the client-facing bits there.
>
> Therefore, I've begun to split up the authentication frontends
> and backends. I've used the DAV philosophy by having providers
> and registering them.
>
> At this point, I have "file" and "dbm" backends which mod_auth_basic
> and mod_auth_digest use. Hopefully, it should be trivial to add a
> "ldap" backend. (mod_auth_basic is essentially mod_auth.)
>
> As it is quite large (diffs are useless), you can find the code here:
>
> http://www.apache.org/~jerenkrantz/new-aaa/
>
> It should be a drop-in replacement to the modules/aaa dir. I've
> got it handling Basic auth requests with both file and dbm backends.
> I've yet to compile digest, but I should have changed the appropriate
> bits to get it to cooperate. mod_auth_{dbm|file}.c does nothing
> except provide the correct auth_provider structure so that the
> authentication front-ends can use them.
>
> Key files:
> mod_auth.h - Header file
> auth_provider.c - Similar to mod_dav's registration of providers
> mod_auth_basic.c - Implementation of basic auth (rewritten)
> mod_auth_digest.c - Implementation of digest auth
> mod_auth_dbm.c - DBM provider
> mod_auth_file.c - File provider
>
> For a file-backed authentication, use:
>
> AuthProvider file
> AuthUserFile conf/dot-user
> AuthType Basic
> AuthName "Test Users"
>
> For a DBM-backed authentication, use:
>
> AuthProvider dbm
> AuthDBMType default
> AuthUserFile conf/dot-user-dbm dbm
> AuthType Basic
> AuthName "Test Users"
>
> (Why AuthUserFile is a Take2 in mod_auth_dbm is unclear. That is
> how it was before.)
>
> I'd like to get this in the tree as I can't really start on the DAV
> ACL stuff until aaa is properly split.
>
> Yes, I realize this breaks configs, but this is the 'right' model to
> move towards (and has been discussed here before, but no one has
> sat down and implemented it). This has the large advantage of
> getting rid of a lot of duplicate code. Hopefully, we could throw
> out the code in server/protocol.c that deals with authentication!
>
> Comments? Thoughts? -- justin
>
Re: authentication rewrite
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Mon, 26 Aug 2002, Justin Erenkrantz wrote:
> I need to be able to get at the authentication backends to implement
> some DAV enhancements - namely DAV has its own authentication model
> (DAV ACL support). My idea would be to allow mod_dav to reuse the
> aaa backends and just implement the client-facing bits there.
>
> Therefore, I've begun to split up the authentication frontends
> and backends. I've used the DAV philosophy by having providers
> and registering them.
http://www.apache.org/~dirkx/aaa.tgz
Has another bit of simplicataion in it. Which may be useful. As to the
propsal below - see other message.
Dw.