Article delegate-en/3349 of [1-5169] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: optional authentication depending on destination (Re: Help with special config)
02 Jul 2006 11:17:35 GMT (Yutaka Sato)
The DeleGate Project

In message <_A3347@delegate-en.ML_> on 07/01/06(20:30:16) I wrote:
 |I think your configuration can be like this:
 |  - anyone can access to a set of servers without authentication
 |  - authenticated users can access to unrestricted servers
 |You can use AUTHORIZER as a local option to each MOUNT point.
 |This might sound natual when you are using DeleGate as an origin server,
 |but it is also applicable to a DeleGate acting as a proxy server.
 |In this case, MOUNT is not used for rewriting but only for access
 |control like this for example.
 |  MOUNT="* = dst=!{host1,host2},AUTHORIZER=-list{user1:pass1,user2:pass2}"
 |This means any accesses to arbitrary hosts (except host1 and host2) are
 |applied this MOUNT.  After this MOUNT is selected, (in the interpretation
 |of HTTP message), it option requires authentication (proxy authentcation
 |to the HTTP client in this case).
 |"* =" means this MOUNT matches any URL and no rewriting is achieved.
 |"dst=!{a list of host}" means this MOUNT is applied when the destination
 |(server) host is not in the list.
 |"AUTHORIZER=-list{a list of pairs of user:pass}" means users must be
 |autorized by username and password in the list to access via this MOUNT.

And there is (should be) yet another way to make this conditional
authorization with the PERMIT parameter as this.


In this case, AUTHORIZER is just used for authentication but not for
authorization, that is, with "-none", DeleGate does authorize any access
with any authentication information even if the authentication is empty.

Users who are authenticated as user1 or user2 in the "-list" are represented
by a pseudo user "authorized", and others are represented with "anon"
where "-none" matches with authentication failure or without authentication.
The first PERMIT allowes unrestricted access for "authorized" users.
The second PERMIT permits any users to access to host1 and host2.

But I found a problem writing this message. There is no definition about
how DeleGate should respond to the requests authenticated as "-none".
It can be with the code 403-Forbidden or 401 or 407-NotAuthenticated but
it's 502-CannotConnect in the current implementation.
I thought it can be cared as REJECT="*:!{host1,host2}:anon@*" but it is
disabled since the modification in 9.0.3.
Originally AUTHORIZER is introduced in 5.4.3 for Telnet to authorize users.
So it is related with several historical problems since AUTHORIZER is
applied to HTTP in 7.2.0.

Since usual HTTP clients does (retry) authentication only when it saw
401/407 code in the response, in this case, it should return 407 when an
access is not permitted by a set of PERMT parameters.

As a conclusion :-), the set of configuration parameters like above should
work as expected.
So I'll modify (fix) DeleGate like the enclosed patch.

  9 9   Yutaka Sato <>
 ( ^ )  National Institute of Advanced Industrial Science and Technology
_<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan
Do the more with the less -- B. Fuller

*** ../../arc/delegate9.2.3-pre7/src/http.c	Mon Jun 26 05:26:51 2006
--- http.c	Sat Jul  1 22:44:52 2006
*** 5553,5555 ****
--- 5553,5558 ----
+ 	/*
  	if( doAuth(Conn,&ident) < 0 || source_permitted(Conn) == 0 ){
+ 	*/
+ 	if( doAuth(Conn,&ident) < 0 || !service_permitted2(Conn,DST_PROTO,1) ){

  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]