Fw: 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
>> >>
>>