You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Patrick Welche <pr...@newn.cam.ac.uk> on 2007/04/27 19:30:16 UTC
SatisfyOne
Basically, bug or configuration error?
Using httpd trunk 529626, of Apr 19 2007, I tried a FAQ configuration
with the new authentication framework:
<Directory "/usr/local/share/httpd/htdocs/learn">
AuthType basic
AuthName "raven test"
AuthBasicProvider file
AuthUserFile /usr/local/etc/pass.txt
<SatisfyOne>
Require host quartz.itdept.newn.cam.ac.uk
Require ip 192.168.200.180
Require valid-user
</SatisfyOne>
</Directory>
quartz% hostname
quartz.itdept.newn.cam.ac.uk
quartz% lynx http://test.itdept.newn.cam.ac.uk/learn
Alert!: Access without authorization denied -- retrying
Username for 'raven test' at server 'test.itdept.newn.cam.ac.uk':
I expected not to be prompted to login by the above configuration.
(also tried AuthBasicAuthoritative Off, and have read the fine manual..)
Cheers,
Patrick
Re: SatisfyOne
Posted by Patrick Welche <pr...@newn.cam.ac.uk>.
On Fri, Apr 27, 2007 at 05:22:16PM -0400, Jim Jagielski wrote:
> Are you sure that there are no other conflicting ACLs?
Yes - it's basically the as-distributed httpd.conf file with the
following addition.
> On Apr 27, 2007, at 1:30 PM, Patrick Welche wrote:
>
> >Basically, bug or configuration error?
> >
> >Using httpd trunk 529626, of Apr 19 2007, I tried a FAQ configuration
> >with the new authentication framework:
> >
> ><Directory "/usr/local/share/httpd/htdocs/learn">
> > AuthType basic
> > AuthName "raven test"
> > AuthBasicProvider file
> > AuthUserFile /usr/local/etc/pass.txt
> > <SatisfyOne>
> > Require host quartz.itdept.newn.cam.ac.uk
> > Require ip 192.168.200.180
> > Require valid-user
> > </SatisfyOne>
> ></Directory>
Re: SatisfyOne
Posted by Jim Jagielski <ji...@jaguNET.com>.
Are you sure that there are no other conflicting ACLs?
On Apr 27, 2007, at 1:30 PM, Patrick Welche wrote:
> Basically, bug or configuration error?
>
> Using httpd trunk 529626, of Apr 19 2007, I tried a FAQ configuration
> with the new authentication framework:
>
> <Directory "/usr/local/share/httpd/htdocs/learn">
> AuthType basic
> AuthName "raven test"
> AuthBasicProvider file
> AuthUserFile /usr/local/etc/pass.txt
> <SatisfyOne>
> Require host quartz.itdept.newn.cam.ac.uk
> Require ip 192.168.200.180
> Require valid-user
> </SatisfyOne>
> </Directory>
>
> quartz% hostname
> quartz.itdept.newn.cam.ac.uk
> quartz% lynx http://test.itdept.newn.cam.ac.uk/learn
> Alert!: Access without authorization denied -- retrying
> Username for 'raven test' at server 'test.itdept.newn.cam.ac.uk':
>
> I expected not to be prompted to login by the above configuration.
> (also tried AuthBasicAuthoritative Off, and have read the fine
> manual..)
>
> Cheers,
>
> Patrick
>
Re: SatisfyOne
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 4/30/2007 at 10:13 AM, in message
<20...@quartz.itdept.newn.cam.ac.uk>, Patrick Welche
<pr...@newn.cam.ac.uk> wrote:
> On Fri, Apr 27, 2007 at 03:44:08PM -0600, Brad Nicholes wrote:
>> >>> On 4/27/2007 at 11:30 AM, in message
>> <20...@quartz.itdept.newn.cam.ac.uk>, Patrick Welche
>> <pr...@newn.cam.ac.uk> wrote:
> ...
>> > Using httpd trunk 529626, of Apr 19 2007, I tried a FAQ configuration
>> > with the new authentication framework:
>> >
>> > <Directory "/usr/local/share/httpd/htdocs/learn">
>> > AuthType basic
>> > AuthName "raven test"
>> > AuthBasicProvider file
>> > AuthUserFile /usr/local/etc/pass.txt
>> > <SatisfyOne>
>> > Require host quartz.itdept.newn.cam.ac.uk
>> > Require ip 192.168.200.180
>> > Require valid-user
>> > </SatisfyOne>
>> > </Directory>
> ...
>> It's beginning to look like Order, Allow, Deny, Satisfy can't be deprecated
> after all. However I still think that there is a usefulness for the same
> type of authorization rules defined by "require".
>
> Indeed, translating to the compat form:
>
> <Directory "/usr/local/share/httpd/htdocs/learn">
> AuthType basic
> AuthName "raven test"
> AuthBasicProvider file
> AuthBasicAuthoritative Off
> AuthUserFile /usr/local/etc/httppwddb
> Order Deny,Allow
> Deny from All
> Allow from quartz.itdept.newn.cam.ac.uk 192.168.200.180
> Require valid-user
> Satisfy Any
> </Directory>
>
> behaves as expected.
>
> Cheers,
>
> Patrick
I'm a little surprised to hear that. Are you sure that you cleared out your authenticated session cache before you tested the new configuration? As the code stands now, you would have had to go through the authentication hook which no matter what the access_control hook said, would have forced a prompt for a user name and password if it didn't already exist in the header. It's always good to hear that things are working correctly, but in this case I am a little surprised.
Brad
Re: SatisfyOne
Posted by Patrick Welche <pr...@newn.cam.ac.uk>.
On Fri, Apr 27, 2007 at 03:44:08PM -0600, Brad Nicholes wrote:
> >>> On 4/27/2007 at 11:30 AM, in message
> <20...@quartz.itdept.newn.cam.ac.uk>, Patrick Welche
> <pr...@newn.cam.ac.uk> wrote:
...
> > Using httpd trunk 529626, of Apr 19 2007, I tried a FAQ configuration
> > with the new authentication framework:
> >
> > <Directory "/usr/local/share/httpd/htdocs/learn">
> > AuthType basic
> > AuthName "raven test"
> > AuthBasicProvider file
> > AuthUserFile /usr/local/etc/pass.txt
> > <SatisfyOne>
> > Require host quartz.itdept.newn.cam.ac.uk
> > Require ip 192.168.200.180
> > Require valid-user
> > </SatisfyOne>
> > </Directory>
...
> It's beginning to look like Order, Allow, Deny, Satisfy can't be deprecated after all. However I still think that there is a usefulness for the same type of authorization rules defined by "require".
Indeed, translating to the compat form:
<Directory "/usr/local/share/httpd/htdocs/learn">
AuthType basic
AuthName "raven test"
AuthBasicProvider file
AuthBasicAuthoritative Off
AuthUserFile /usr/local/etc/httppwddb
Order Deny,Allow
Deny from All
Allow from quartz.itdept.newn.cam.ac.uk 192.168.200.180
Require valid-user
Satisfy Any
</Directory>
behaves as expected.
Cheers,
Patrick
Re: SatisfyOne
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 4/30/2007 at 9:54 AM, in message
<e4...@mail.gmail.com>, "Joshua Slive"
<jo...@slive.ca> wrote:
> On 4/27/07, Brad Nicholes <BN...@novell.com> wrote:
>
>>
>> It's beginning to look like Order, Allow, Deny, Satisfy can't be deprecated
> after all. However I still think that there is a usefulness for the same
> type of authorization rules defined by "require".
>>
>
> I don't really understand why you say this. Isn't it just a question
> of defining the order of evaluation of <SatisfyOne> blocks? And the
> proper order seems quite straight-forward to me.
>
> Joshua.
Well, the reason why is because of the order in which the hooks are called . We have three different hooks, access_checker, check_user_id and auth_checker. Basically, to give the hooks more understandable names, we have access_control, authentication and authorization. The directives that cause these hooks to be invoked are:
Order, Allow from, Deny from- access_control hook
AuthBasicProvider, AuthDigestProvider - Authentication hook
Require - Authorization hook
With the host based directives moving from "Allow from [host|IP|ENV]", "Deny From [host|IP|ENV]" to "Require [host|IP|ENV]", "Reject [host|IP|ENV]", the access control functionality moved from the access_control hook to the Authorization hook. This works great until you try to throw authentication into the mix. If your intention was to avoid a credentials challenge through access control, as soon as you include authentication, the check_user_id hook gets called and the first thing that happens is a check for the user name and password in the request header. If it isn't there, the challenge is sent back to the browser and the browser prompts for the user name and password. In this case there was no chance for "Require [host|IP]" to even have a crack at satisfying the request since the authorization hook was never called.
When I implemented this I thought I had all of the bases covered but apparently not (which is why I would like to see us at least roll an alpha of 2.3 so this stuff would get some visibility). There seems to be cases where access control and authorization should be separate. So I am starting to see the need to retain Order, Allow, Deny, Satisfy so that in cases where access control needs to happen outside of authorization, it can. I don't really like having to retain those directives, because it makes access control and authorization a little more confusing.
Better ideas?
Brad
Re: SatisfyOne
Posted by Joshua Slive <jo...@slive.ca>.
On 4/27/07, Brad Nicholes <BN...@novell.com> wrote:
>
> It's beginning to look like Order, Allow, Deny, Satisfy can't be deprecated after all. However I still think that there is a usefulness for the same type of authorization rules defined by "require".
>
I don't really understand why you say this. Isn't it just a question
of defining the order of evaluation of <SatisfyOne> blocks? And the
proper order seems quite straight-forward to me.
Joshua.
Re: SatisfyOne
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 4/27/2007 at 11:30 AM, in message
<20...@quartz.itdept.newn.cam.ac.uk>, Patrick Welche
<pr...@newn.cam.ac.uk> wrote:
> Basically, bug or configuration error?
>
> Using httpd trunk 529626, of Apr 19 2007, I tried a FAQ configuration
> with the new authentication framework:
>
> <Directory "/usr/local/share/httpd/htdocs/learn">
> AuthType basic
> AuthName "raven test"
> AuthBasicProvider file
> AuthUserFile /usr/local/etc/pass.txt
> <SatisfyOne>
> Require host quartz.itdept.newn.cam.ac.uk
> Require ip 192.168.200.180
> Require valid-user
> </SatisfyOne>
> </Directory>
>
> quartz% hostname
> quartz.itdept.newn.cam.ac.uk
> quartz% lynx http://test.itdept.newn.cam.ac.uk/learn
> Alert!: Access without authorization denied -- retrying
>
> Username for 'raven test' at server 'test.itdept.newn.cam.ac.uk':
>
>
> I expected not to be prompted to login by the above configuration.
> (also tried AuthBasicAuthoritative Off, and have read the fine manual..)
>
> Cheers,
>
> Patrick
This is probably a bug. The problem is that as soon as you specify an Auth provider, the code is going to go through the check_user_id hook. The first thing that auth_basic will do in the hook is try to get the user and password. If it can't, it immediately returns HTTP_UNAUTHORIZED which causes the browser challenge. You can still use mod_access_compat and define access control rules which is probably what you really want rather than authorization rules, which is what you have defined here. However there is still a problem in ap_process_request_internal() in request.c. In the current code, there is no precedence defined between access control and authentication. All hooks will be called on all requests. We can either set the precedence at the time when the hooks are called (which will prevent some hooks from being called) or let the auth hooks themselves determine the precedence.
It's beginning to look like Order, Allow, Deny, Satisfy can't be deprecated after all. However I still think that there is a usefulness for the same type of authorization rules defined by "require".
Brad
Re: SatisfyOne
Posted by Jorge Schrauwen <jo...@gmail.com>.
What does a reverse lookup of 192.168.200.180 on the server give as hostname?
On 4/27/07, Patrick Welche <pr...@newn.cam.ac.uk> wrote:
> On Fri, Apr 27, 2007 at 01:55:47PM -0400, Joshua Slive wrote:
> > Just to eliminate the obvious, have you actually checked the
> > access_log to verify that the IP address/hostname reported there match
> > your Require directives?
>
> Sadly yes:
>
> 192.168.200.180 - - [27/Apr/2007:17:14:42 +0100] "GET /learn HTTP/1.0" 401 1343
> 192.168.200.180 - - [27/Apr/2007:17:15:36 +0100] "GET /learn HTTP/1.0" 401 1306
> 192.168.200.180 - - [27/Apr/2007:18:03:16 +0100] "GET /learn HTTP/1.0" 401 1306
> 192.168.200.180 - - [27/Apr/2007:18:29:46 +0100] "GET /learn HTTP/1.0" 401 1306
> 192.168.200.180 - - [27/Apr/2007:18:42:23 +0100] "GET /learn HTTP/1.0" 401 1297
>
> which matches at least the require ip.
>
> > Otherwise, I agree that you shouldn't be getting a login prompt.
>
> Hmm... What to try next...
>
> Cheers,
>
> Patrick
>
--
~Jorge
Re: SatisfyOne
Posted by Patrick Welche <pr...@newn.cam.ac.uk>.
On Fri, Apr 27, 2007 at 01:55:47PM -0400, Joshua Slive wrote:
> Just to eliminate the obvious, have you actually checked the
> access_log to verify that the IP address/hostname reported there match
> your Require directives?
Sadly yes:
192.168.200.180 - - [27/Apr/2007:17:14:42 +0100] "GET /learn HTTP/1.0" 401 1343
192.168.200.180 - - [27/Apr/2007:17:15:36 +0100] "GET /learn HTTP/1.0" 401 1306
192.168.200.180 - - [27/Apr/2007:18:03:16 +0100] "GET /learn HTTP/1.0" 401 1306
192.168.200.180 - - [27/Apr/2007:18:29:46 +0100] "GET /learn HTTP/1.0" 401 1306
192.168.200.180 - - [27/Apr/2007:18:42:23 +0100] "GET /learn HTTP/1.0" 401 1297
which matches at least the require ip.
> Otherwise, I agree that you shouldn't be getting a login prompt.
Hmm... What to try next...
Cheers,
Patrick
Re: SatisfyOne
Posted by Joshua Slive <jo...@slive.ca>.
On 4/27/07, Patrick Welche <pr...@newn.cam.ac.uk> wrote:
> I expected not to be prompted to login by the above configuration.
> (also tried AuthBasicAuthoritative Off, and have read the fine manual..)
Just to eliminate the obvious, have you actually checked the
access_log to verify that the IP address/hostname reported there match
your Require directives? (For example, if you are testing on the same
host, you may be coming in over the loop-back 127.0.0.1/localhost.)
Otherwise, I agree that you shouldn't be getting a login prompt.
Joshua.