Re: Web Server Authentication

Hi Florencia and Leo,


> Ive changed the thread name, because it became "misleading".
> 
> Thanks for your answer, and confirmation on the variable used by Genero web
> clients. But can you tell me where in Genero docs can I find about
> FGL_WEBSERVER_REMOTE_USER ? I want to read it again, and see if I'm not
> missing anything. When I added that to our library, we were just testing,
> and know we are actually migrating, and I want to re-check this.

Sorry, it was in old documentation 3.20 of WebFE.
We will add this to the GAS documentation.

[...]
environment variables transmitted to the CGI application, by prefixing them with FGL_WEBSERVER_. Those environment variables will be set by the Application Server before running the DVM.
[...]

Which means REMOTE_USER transmitted by the CGI becomes FGL_WEBSERVER_REMOTE_USER.
Any environment variable xxx transmitted to GCI becomes FGL_WEBSERVER_xxx.

> So, as far as Genero Web clients are concerned, I'm done for now (but please
> send me the documentation).
> 
> But what about BDS ? I'm not sure I understand. Do you mean last versions of
> cli-java are still using FGL_AUTHUSER ? No matter what that mail of April
> 2nd. 2003 says ? In that case, I could change in the cjac.cnf, and change
> REMOTEUSER to FGL_WEBSERVER_REMOTE_USER, so I can use that only variable
> name in my programs ? And what about cli-html 3.5x ? How is that managed ?

With any client that uses WebFE (which is BDS Cli-Html Client) or GAS or GWC for deployment the FGL_WEBSERVER_ mechanism is the same. The variables are only set if you use a webserver (cgi or isapi)

So the products you listed below are using FGL_WEBSERVER_REMOTE_USER
- BDS Cli-Html Client
- BDS Cli-Java Client
- Genero GDC-AX
- Genero Java Client
- Genero Web Client

> So this way, if I use FGL_WEBSERVER_REMOTE_USER for all Web Authenticated
> users, I can assure no future local Authentication (like : SSH, Telnet or
> Rlogin) will use that variable name, as it starts with FGL_    ;-)

I don't understand your problem here.
Do you mean, you want to use direct connection with GDC for example, and this set FGL_WEBSERVER_REMOTE_USER ?
If you want to differenciate the connection types through web server or direct connection to DVM, just test if FGL_WEBSERVER_REMOTE_USER is empty or not. If it's empty you are in direct connection so you can use REMOTEUSER instead.

Was this your issue ?

Thanks.
-- 
____________________________________________________________

Sisavanh SENGSAVANH                    European Support Team
mailto:[email protected]           Phone: +33 (0)3 88 18 61 24
Four J's Development Tools - Genero, It speaks your language
http://www.4js.com 
 
> Thanks,
> 
> Florencia
> 
>> -----Mensaje original-----
>> De: [email protected] 
>> [mailto:[email protected]] En nombre de Leo Schubert
>> Enviado el: Martes, 28 de Febrero de 2006 14:51
>> Para: [email protected]
>> Asunto: Fw: [fourjs-users] Unrespected Password Problem
>>
>>
>> Hi Florencia, I got the following from the Genero HTML client team  :
>>> Florencia is right. All front ends connected on the GAS, the 
>> GWC or the 
>>> WebFE send the user which has been authenticated by the browser, 
>>> through the FGL_WEBSERVER_REMOTE_USER environment variable.
>> So this affects all Genero products which go thru the Genero 
>> GAS. I have no clue, if BDS HTML/java client uses another 
>> GAS/App server than the Genero one,you should 
>> know this better than me...
>> Seems you need to add a check in your login scripts/programs 
>> that this variable was additionally set 
>> and go ahead depending if FGL_AUTHUSER or 
>> FGL_WEBSERVER_REMOTE_USER was set. In the WTK case you can 
>> 'fake' a variable of your choice (export 
>> FGL_AUTHUSER=`whoami`,or REMOTEUSER or 
>> FGL_WEBSERVER_REMOTEUSER) so that you don't need to 
>> differentiate inside your programs if the user 
>> was coming from the HTML client or WTK. From my outside 
>> perspective this seems realtively easy to 
>> do, but of course the problems appear always in the 
>> details...:-) Kind Regards, Leo
>>
>>
>> ----- Original Message ----- 
>> From: "Florencia Vitale" <[email protected]>
>> To: <[email protected]>
>> Sent: Tuesday, February 28, 2006 3:39 PM
>> Subject: RE: [fourjs-users] Unrespected Password Problem
>>
>>
>>> Hi Leo,
>>>
>>> I don't need REMOTEUSER variable. In fact, the problem is that 
>>> REMOTEUSER is now being automatically filled in by Linux 
>> (or at least 
>>> by Red Hat's linux) "rlogin" servers, when it previously wasn't.
>>>
>>> I'll give you some more background info, so you can understand my 
>>> problem :
>>>
>>> We have an internal function library which identificates 
>> the user name 
>>> that "uses" our app. Due to old issues with LOGNAME variable on 
>>> different Unix platforms, we decided to identify the user's 
>> name, with 
>>> "SELECT user FROM table_with_one_row". That way we always 
>> got the real 
>>> user name that the "login" identified. With LOGNAME you got 
>> different 
>>> results depending if it came from a "login" or an "su" command. I 
>>> don't know if this is still an issue, or if it has been unified 
>>> somehow, but with the SELECT method it worked for years, and still 
>>> does.
>>>
>>> But, when "Web connections" appeared, with cli-html and 
>> cli-java, we 
>>> needed another way to authenticate REMOTE Users. Why ? Because the 
>>> USER identified at the server (unix or linux) is always the 
>> same user, 
>>> the one that runs the Application Server (fglhtmld, fglasd, gasd, 
>>> ...). So, in the case the app is running through an App Server, we 
>>> need another way to get the "Authenticated Web Server User".
>>>
>>> We could have used our own "login" function, but as we were 
>> also using 
>>> the Web Servers Authentication functions, it seemed rather 
>> clumsy to 
>>> ask for the username twice. So we decided to rely on the Web Server 
>>> Authentication.
>>>
>>> So in cli-java, the proposed method, that came in the cli-java 
>>> documentation, and also on the default cjac.cnf, was to use a 
>>> REMOTEUSER variable instantiated with FGL_AUTHUSER. Why not 
>> directlye 
>>> FGL_AUTHUSER ? I don't know, it was FourJ's recomendation, and we 
>>> followed. So we added to our custom library a 
>> FGL_GETENV("REMOTEUSER") 
>>> block. If that variable was not null, we used that 
>> username, if not, 
>>> it means that it's not a "remote web user" and so we use 
>> the "SELECT 
>>> user FROM ...." method, which still works for all "local" (ssh, 
>>> telnet, rlogin, ...) connections.
>>>
>>> And now, with Genero, we found out that REMOTEUSER or 
>> FGL_AUTHUSER did 
>>> no longer worked, but that a new environment variable appeared : 
>>> FGL_WEBSERVER_REMOTE_USER. I couldn't find where that variable is 
>>> documented. I searched ALL my mails (from the user lists, 
>> from fourj's 
>>> support, etc.) and all the Genero online and downloaded 
>> documentation, 
>>> and could not find it. But I tested it again (as our apps in Genero 
>>> are still under migration proccess), and it works.
>>>
>>> So, giving all that background I need to know what is the 
>> way to get 
>>> the "remote authenticated user". And if there isn't only 
>> one method, I 
>>> need one for each of the following web clients :
>>>
>>> - BDS Cli-Html Client
>>> - BDS Cli-Java Client
>>> - Genero GDC-AX
>>> - Genero Java Client
>>> - Genero Web Client
>>>
>>> As said before, I could not find that in the docs, but I 
>> came across 
>>> the FGL_WEBSERVER_REMOTE_USER for Genero, so somewhere it must be.
>>>
>>> But I still need to know about the BDS Cli-HTML and 
>> Cli-Java clients, 
>>> as those environments are still in production. In fact it was on a 
>>> customer with BDS, with a Linux Server and using "ilogin" 
>> connections 
>>> that all this came up.
>>>
>>> For now, as a workarround, we modified our library, and 
>> commented the 
>>> line where we obtained REMOTEUSER variable. But we need to 
>> modify that 
>>> function for good, with the actual definition of "how to obtain the 
>>> Remote Authentication Username".
>>>
>>> Thanks,
>>>
>>> Florencia
>>>
>>>> -----Mensaje original-----
>>>> De: [email protected] 
>> [mailto:[email protected]] En 
>>>> nombre de Leo Schubert Enviado el: Martes, 28 de Febrero de 2006 
>>>> 08:49
>>>> Para: [email protected]
>>>> Asunto: Re: [fourjs-users] Unrespected Password Problem
>>>>
>>>>
>>>> Hi Florencia, I'm afraid I can't follow you completely.
>>>> To set the environment variable REMOTEUSER at your server side 
>>>> correctly with WFE 3.54 you can use the following command line for 
>>>> ilogin (in case you want the name of the logged in UNIX user in
>>>> REMOTEUSER): export REMOTEUSER=`whoami`;@FGL;fglrun yourapp;exit
>>>>
>>>> (in case you want the name of the WFE Windows user in
>>>> REMOTEUSER): export REMOTEUSER=@USR;@FGL;fglrun yourapp;exit
>>>>
>>>> because the command line is sent after the rlogin protocol was 
>>>> successfully handled the rlogin daemon cannot change REMOTEUSER 
>>>> anymore. But be careful if you set REMOTEUSER in your login script,
>>>> I guess you have something like that:
>>>> @FGL;myscript.sh;exit
>>>> and myscript.sh calls fglrun after a bunch of environment
>>>> settings which might also set
>>>> REMOTEUSER...
>>>>
>>>>> (*1) REMOTEUSER obtains the value of the first USER set in
>>>> the ilogin
>>>>> "User" field. If you change it and then login, you keep 
>> getting the 
>>>>> original one. This is the BUG.
>>>> Does this mean that if you change the name in the "User" 
>> field that 
>>>> you don't log in under the new User name,but as the user which was 
>>>> typed in the first time? That would be really a bug . Or is just
>>>> REMOTEUSER broken ?
>>>> Kind Regards, Leo
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Florencia Vitale" <[email protected]>
>>>> To: <[email protected]>
>>>> Sent: Monday, February 27, 2006 6:38 PM
>>>> Subject: RE: [fourjs-users] Unrespected Password Problem
>>>>
>>>>
>>>>> Hi Leo,
>>>>>
>>>>> I've done the tests based on you mail and my conclusion 
>> is that the 
>>>>> default value of LOCAL_USER should be ok for us. The
>>>> problem is that
>>>>> the variable USER is wrongly set, when you change users.
>>>>>
>>>>> I've done the tests, on :
>>>>>
>>>>> DVM 3.54.1a (under 3 different OS)
>>>>> WFE 3.54.2e (all under XP)
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>> -
>>>>> ------
>>>>> ---------------------------------------
>>>>> O.S. LOCAL_USER=USER LOCAL_USER=@USR or @USERNAME 
>>>>> LOCAL_USER=@ENV{LOGNAME}
>>>>>
>>>> --------------------------------------------------------------
>>>> --------------
>>>>> ---------------------------------------
>>>>> Fedora Core 4 REMOTEUSER (*1) REMOTEUSER (*2)
>>>>> empty REMOTEUSER (*3)
>>>>> Red Hat 8.0 REMOTEUSER (*1) REMOTEUSER (*2)
>>>>> empty REMOTEUSER (*3)
>>>>> Solaris 8 unset REMOTEUSER unset REMOTEUSER
>>>>> unset REMOTEUSER
>>>>>
>>>> --------------------------------------------------------------
>>>> --------------
>>>>> ---------------------------------------
>>>>>
>>>>> (*1) REMOTEUSER obtains the value of the first USER set in
>>>> the ilogin
>>>>> "User" field. If you change it and then login, you keep 
>> getting the 
>>>>> original one. This is the BUG.
>>>>>
>>>>> (*2) REMOTEUSER gets the "windows network username" no 
>> matter what 
>>>>> username I use to login on the Linux/Unix server. This is
>>>> not what I
>>>>> need, maybe it's usefull for others.
>>>>>
>>>>> (*3) REMOTEUSER is set, but has an Empty value, even though
>>>> LOGNAME is
>>>>> set in the Linux/Unix environment.
>>>>>
>>>>> On Solaris the variable REMOTEUSER is always "unset" (not
>>>> empty, just
>>>>> unset).
>>>>>
>>>>> Then I tried to find out WHY we use that variable 
>> REMOTEUSER, and 
>>>>> tracked it down to cli-java. In cli-java, in the cjac.cnf
>>>> file, it is
>>>>> set with FGL_AUTHUSER (it came on the original example), so
>>>> we used it
>>>>> to obtain the REMOTE Username authenticated by the Web 
>> Server. It 
>>>>> never caused problems before, because we don't much use
>>>> "ilogin", and
>>>>> maybe most of the customers that do use it, have Unix
>>>> servers. So this
>>>>> problem hadn't happen before.
>>>>>
>>>>> So, I guess setting the REMOTEUSER variable is not a
>>>> FourJ's problem,
>>>>> so we can stop using it.
>>>>>
>>>>> But now we need to have another way to obtain the Remote 
>> Web Server 
>>>>> User, and we need a way that can work across all front-ends
>>>> (BDS and
>>>>> Genero) or to know excatly how to do it for each 
>> front-end to build 
>>>>> internal libraries to obtain that "user".
>>>>>
>>>>> Some more info on this matter :
>>>>>
>>>>> 1) in a mail with subject "[fourjs-users] Product News - 
>> Four J's 
>>>>> Business Development Suite 3.53 (FOUR J'SJAVA FRONT END)"
>>>> from April
>>>>> 2nd. 2003, it says :
>>>>>
>>>>>   ~ All JFE previous versions had specialized way to manage
>>>> browsers
>>>>> authentification
>>>>>     (via the variable FGL_AUTHUSER) and parameters passed via an 
>>>>> URL.
>>>>>     In this version, all these features follow the same
>>>> standard than
>>>>> Web Front End.
>>>>>
>>>>> ~ For more information, please see the Discovering Web Front End 
>>>>> 3.53 documentation.
>>>>>
>>>>> I read that "Discovering WFE 3.53 documentation" and 
>> couldn't find 
>>>>> anything about it.
>>>>>
>>>>> 2) I searched all Genero documentation and couldn't find
>>>> how that same
>>>>> thing (Web Auth) is done in Genero. What I did found out
>>>> was that in
>>>>> our already "converted to Genero" programs, instead of using 
>>>>> REMOTEUSER, we are using a variable
>>>> "FGL_WEBSERVER_REMOTE_USER". I've
>>>>> searched all bds and genero user lists mails, and all my FourJ's 
>>>>> support mails, and couldn't find out where I got that info
>>>> from. But
>>>>> I've tested it with GDC-AX enabling HTTP Auth, and it works.
>>>>>
>>>>> So, if I want to use only one method for all the front
>>>> ends, is that
>>>>> FGL_WEBSERVER_REMOTE_USER the actual variable for all web
>>>> front-ends
>>>>> in BDS and Genero ? If so, can you point out the 
>> documentation so I 
>>>>> can analyze this further ?
>>>>>
>>>>> And if there isn't one unique way, can you tell me for each
>>>> of these
>>>>> front-ends, which is the way to obtain the Authenticated User ?
>>>>>
>>>>> - BDS Cli-Html Client
>>>>> - BDS Cli-Java Client
>>>>> - Genero GDC-AX
>>>>> - Genero Java Client
>>>>> - Genero Web Client
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Florencia
>>>>>
>>>>>> -----Mensaje original-----
>>>>>> De: [email protected]
>>>> [mailto:[email protected]] En
>>>>>> nombre de Leo Schubert Enviado el: Miércoles, 22 de
>>>> Febrero de 2006
>>>>>> 12:44
>>>>>> Para: [email protected]
>>>>>> Asunto: Re: [fourjs-users] Unrespected Password Problem
>>>>>>
>>>>>>
>>>>>> MensajeHi Florencia,
>>>>>> it's true, by default WTK sets local user and remote user
>>>> to the same
>>>>>> value when logging in to a remote host via "rlogin" protocol. 
>>>>>> However we added a resource in WTKSRV.INI to surround 
>> this (since 
>>>>>> version 3.54.1a) : [RLOGIN]
>>>>>>
>>>>>> ;;;;;;;;;;;;;;;;;;
>>>>>> ; Specify the local user sent in the rlogin protocol
>>>>>> ; by default LOCAL_USER = USER
>>>>>> ; you will need to set this explicitly here if the local
>>>> user ; is a
>>>>>> different one ; Default: value of USER ; LOCAL_USER can be: ;
>>>>>> ;1. a real user name foo
>>>>>> ;2. @USR -> the OS function GetUserName() is called
>>>>>> ;3. @USERNAME -> the environment variable USERNAME is used
>>>>>> ;4. @ENV{envname} -> an environment variable of choice is
>>>>>> used ;  ( @ENV{MYUSER} for example )
>>>>>>
>>>>>>
>>>>>> LOCAL_USER=@USR
>>>>>>
>>>>>> In your case I suggest to set LOCAL_USER TO "@USR" to let
>>>> WTK fill in
>>>>>> the actual Windows user name of the local user.
>>>>>> I didn't know that the REMOTEUSER environment variable is now
>>>>>> set automagically from the rlogin
>>>>>> daemon, but I can't find any note about that in the original
>>>>>> RFC's 1258 and 1282  . Also the rlogin
>>>>>> man page doesn't mention this. Is there any man page where I
>>>>>> can find this ? Kind Regards, Leo
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: Florencia Vitale
>>>>>> To: [email protected]
>>>>>> Sent: Wednesday, February 22, 2006 3:14 PM
>>>>>> Subject: RE: [fourjs-users] Unrespected Password Problem
>>>>>>
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> On this mail I'll give some more feedback on our actual
>>>> problem, so
>>>>>> to not lead to wrong conclusions.
>>>>>>
>>>>>> First of all, the case where the user typed in 3 times a wrong
>>>>>> password, we could not yet reproduce. I'll try to send a
>>>> consultant
>>>>>> to the customer asap, to clarify this. The customer
>>>> insist's on this
>>>>>> issue, and sends me printscreens, and all that, but I cannot
>>>>>> confirm for sure. And the consultant
>>>>>> that wen't last time, he didn't see that case really, but the
>>>>>> other one. Where the user changed the
>>>>>> username after the second failure, and succeeded login in
>>>>>> with that second account, but saw the
>>>>>> first username on the terminal window, and on our application
>>>>>> first screen.
>>>>>>
>>>>>> So here's my feedback on that second case (changin usernames) :
>>>>>>
>>>>>> The problem wasn't a security issue at all, but a bug 
>> (anoying but
>>>>>> not so critical) in the "ilogin" application. What 
>> happens is that
>>>>>> "ilogin" sets the REMOTEUSER variable on the Linux server, with
>>>>>> the original username, the one defined as default in the
>>>>>> shortcut, or the first one you set if there
>>>>>> was no default user, and not with the user that finally 
>> logged in.
>>>>>> I found out, because I could finally reproduce it here, against
>>>>>> Fedora Core 4, and there I saw that the Linux user was 
>> Ok. (with a
>>>>>> "who" from another session). But the database conection 
>> user, was
>>>>>> wrong. And that was because in our programs we use REMOTEUSER
>>>>>> if it's set, as the Connection and
>>>>>> Application user. If it's not set, we use the "SELECT user
>>>>>> FROM table_with_one_row". We use the
>>>>>> REMOTEUSER because when we run a program from cli-java or
>>>>>> from GASD (in Genero) the Application
>>>>>> Server always connects to the database with the same user,
>>>>>> which is the user that runs the daemon.
>>>>>> But we need the real username, which we obtain with
>>>>>> REMOTEUSER, when the user authenticates with
>>>>>> HTTP Auth, or any other Auth system we choose.
>>>>>>
>>>>>> So, the bug can be divided into 2 problems :
>>>>>>
>>>>>> - upon "ilogin" the internal variable @USER is wrongly
>>>> set. It always
>>>>>> shows as the original
>>>>>> (default) user. This is shown on the ilogin terminal window and
>>>>>> confuses the user. This is not critical, and most of 
>> the times we
>>>>>> don't even show the terminal window, in fact we only 
>> activated it
>>>>>> for debugging issues.
>>>>>>
>>>>>> - the major problem is that probably that same @USER
>>>> variable is the
>>>>>> one that ilogin uses to set the server REMOTEUSER
>>>> variable. This is
>>>>>> only done with Linux servers, on Unix servers it doesn't
>>>>>> populate that variable at all, as in fact it's not a remote
>>>>>> user, but a user from the same server
>>>>>> it's authenticating the login. So I guess, it shouldn't be
>>>>>> populated on Linux, as it's not on Unix,
>>>>>> and also the @USER should be populated with the actual user
>>>>>> that logged in.
>>>>>>
>>>>>> I hope this give's some light upon my previous mail.
>>>>>>
>>>>>> Florencia
>>>>>>
>>>>>> -----Mensaje original-----
>>>>>> De: [email protected]
>>>> [mailto:[email protected]] En
>>>>>> nombre de Florencia Vitale Enviado el: Jueves, 16 de
>>>> Febrero de 2006
>>>>>> 11:39
>>>>>> Para: [email protected]
>>>>>> Asunto: RE: [fourjs-users] Unrespected Password Problem
>>>>>>
>>>>>>
>>>>>> Hi Jennifer,
>>>>>>
>>>>>> Well, yes, it happened to a customer of us, too.
>>>>>>
>>>>>> If you search for a thread with subject "Ilogin Authentication
>>>>>> problem" you'll see what I posted. But I got no real answer from
>>>>>> fourjs. After several tests here, in my environment, I
>>>> found that the
>>>>>> username was wrong on the window header, but the real user
>>>>>> had logged in.
>>>>>>
>>>>>> Then the customer insisted that that was not their 
>> case, and they
>>>>>> showed me that not changing the user, but putting the
>>>> wrong password
>>>>>> 3 times, lets the user log in, with that username, as it's then
>>>>>> showed in the firt screen of out application where we show
>>>>>> the username obtained from the database
>>>>>> engine.
>>>>>>
>>>>>> But after Oliver's answer (see last mail of my thread)
>>>> I've tried to
>>>>>> solve this issue with our local support. No solution yet !!!
>>>>>>
>>>>>> Florencia
>>>>>> -----Mensaje original-----
>>>>>> De: [email protected]
>>>> [mailto:[email protected]] En
>>>>>> nombre de Jennifer Yu Enviado el: Miércoles, 15 de 
>> Febrero de 2006
>>>>>> 18:22
>>>>>> Para: [email protected]
>>>>>> Asunto: [fourjs-users] Unrespected Password Problem
>>>>>>
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Has anybody come across the problem where a user may type in any
>>>>>> password and still log onto the Windows Front End?  We
>>>> noticed this
>>>>>> issue in January 2006, but did not have this problem in the
>>>>>> previous years of using this product.  Our wtksrv files have
>>>>>> not been modified.  Telnet connection
>>>>>> to the system still checks if the entered password matches
>>>>>> what is saved for the user.
>>>>>>
>>>>>> Hopefully a solution exists since it is a security problem.
>>>>>>
>>>>>> Regards,
>>>>>> Jennifer
>>>>>>
>