Re: SatisfyOne
On 4/30/2007 at 10:13 AM, in message [EMAIL PROTECTED], Patrick Welche [EMAIL PROTECTED] wrote: On Fri, Apr 27, 2007 at 03:44:08PM -0600, Brad Nicholes wrote: On 4/27/2007 at 11:30 AM, in message [EMAIL PROTECTED], Patrick Welche [EMAIL PROTECTED] 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
On 4/27/07, Brad Nicholes [EMAIL PROTECTED] 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
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
On Fri, Apr 27, 2007 at 03:44:08PM -0600, Brad Nicholes wrote: On 4/27/2007 at 11:30 AM, in message [EMAIL PROTECTED], Patrick Welche [EMAIL PROTECTED] 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
On 4/30/2007 at 9:54 AM, in message [EMAIL PROTECTED], Joshua Slive [EMAIL PROTECTED] wrote: On 4/27/07, Brad Nicholes [EMAIL PROTECTED] 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
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
On 4/27/07, Patrick Welche [EMAIL PROTECTED] 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.
Re: SatisfyOne
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
What does a reverse lookup of 192.168.200.180 on the server give as hostname? On 4/27/07, Patrick Welche [EMAIL PROTECTED] 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
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
On 4/27/2007 at 11:30 AM, in message [EMAIL PROTECTED], Patrick Welche [EMAIL PROTECTED] 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
