Article delegate-en/1039 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: How to authenticate users?
28 Feb 2001 21:50:37 GMT

>  |Now, I have written a perl script that can access the RADIUS server,
>  |and determine whether a user name / password is valid, based on the
>  |code here, and using it as a FFROMCL script:
> FFROMCL is not recommended in your case since its overhead is heavy
> especially when used with light weight protocol like HTTP.

I thought this would be the case, after seeing what it does.  It also
acts only as a filter, passing stdin from the browser's output stream
and passing stdout to the back end server, i.e. there's no way for it
to write back to the browser's input stream.  This should probably
be documented better somewhere.

>  |        AUTH=proxy:pauth \
> Since your DeleGate is working as if it is an origin server from the
> viewpoint of client,
>   AUTH=origin:auth 

I did not see any documentation for the AUTH=origin:auth parameter in the
reference manual.  I can see AUTH=proxy:auth.

Anyway, I tried this and it appears to work OK.

> is a proper parameter.  AUTH=proxy:pauth requires 
> "Proxy-Authorization:"
> which will be consumed at a client side proxy server if exists.

I think this is my problem because the client side browser is almost
certainly coming through a proxy server.  I have stopped using proxy:pauth
and started using proxy:auth.  I haven't tried origin:auth, what would be
the difference between origin:auth and proxy:auth?

> No. AUTH=origin:auth with PERMIT="*:*:*@authhost" allows access only
> if a request contains Authorization with a username in a form of
> "xxx@authhost" with a password "yyy", and login to ftp://authhost
> with the username "xxx" and the password "yyy" succeeds.
> This design is not good in two points: requiring "@authhost" for
> clients can be undesirable, and standard port of FTP (21) can be
> unavailable for an authentication server (which may be programmed
> by users) for DeleGate.
> AUTHORIZER, which was introduced later, solved these problem.
> With this, "@authhost" part is not required, and
> AUTHORIZER=authhost/9999 will use auth-server at port 9999 on 
> authhost.
> But it has not been applicable to HTTP yet.  So I made a tentative
> patch and enclosed. It will enable a usage like:
>   AUTH=origin:auth          ... require Authorization
>   AUTHORIZER=authhost/port  ... authenticated as 
> ftp://user:pass@authhost:port
>   PERMIT="*:*:*@authhost"   ... allow everyone if authorized 
> at authhost

The parameters I have ended up using are as follows:

        AUTH=proxy:auth \
        PERMIT="*:*:{*,!?}@*" \
        AUTHORIZER="localhost" \

I did not need to run an FTP server on localhost for any reason other
than using it for delegate authentication, so I just used the standard
FTP port 21 and did not need to use "AUTHORIZER=localhost/someport",
although I could have done so.

(What does "(*,!?)" do, and how is it different to just "*" ?? ).

Also, if a user does not enter a host name in the "user@host" part it
authenticates to localhost (this is a default in one of the C files,
as I recall).

> I wrote about how to make an authorizer, which act as a FTP server,
> by yourself  in the article:
> <URL:>

I also did this using a standard PAM compliant FTP server.  Now, what
I really wanted to do was authenticate against a RADIUS server, so I
set up the FTP server to authenticate to RADIUS.  On Red Hat Linux,
I did it by modifying the /etc/pam.d/ftp file to read:

auth        required    /lib/security/
account     required    /lib/security/
session     required    /lib/security/

(note I needed to fetch the pam_radius_auth module from because the pam_radius module
provided with RedHat does not do authentication, only session).

Then, of course, I needed to set up the /etc/raddb/server file to
contain the following line:

RadiusServer	SeCreTKeY		5

RadiusServer = IP address or host name of RADIUS server
SeCreTKeY	 = RADIUS shared secret key
5		 = time out value.

I also needed the /etc/raddb/dictionary file from my ICRADIUS

Note that ICRADIUS also supports PAM, so I had no troubles getting
ICRADIUS to authenticate NT domain users against an NT domain
server, or domain controller.

Thanks for your help, and delegate is turning out to be a very
useful software tool!  I hope you can distribute RPM packages
of this program soon.


This e-mail message has been scanned and cleared by MailMarshal

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