We have been a WebFOCUS shop for over 10 years. We have a self service environment where users log into WebFOCUS with their IBM mainframe RACF credentials. After they are validate on the mainframe, an html page appears allowing users to select reports to run. An html page passes the user selected values to dialogue manager variables within the FOCEXECs on the mainframe. We do not user MRE or Dev Studio. Our environment is home grown.

Yesterday, all access to the mainframe was revoked and had to repoint WebFOCUS to access the hordes of data I had downloaded to our WebFOCUS server (Windows Server 2003). I went through the various configuration files and removed all references to the mainframe. In the main signon page, I changed the IBIC_server reference from EDAUSER to EDASERVE. Users must now enter the ADS credentials instead of their RACF ones.

Everything seemed as though it was going great until a user called and stated he had entered a misspelled user name and still got into the system. I tried it myself and nearly had a heart attack. Since I have always relied on the mainframe to authenticate users, I never expected this would be a problem when migrating the login process to the server. I spent the day changing and rechanging the config files.

While echoing the contents of my startup FOCEXECs, I determine that it didn’t matter what user name or password I entered into the main signon page. WebFOCUS knew who I was and all of the DBA security I put in place still worked. Even when I did a get user, it returned who I really was. It’s like the main login page serves no purpose. As long as a person has logged into their computer, WebFOCUS knows who they are.

I do not know how all of this works but someone, especially in senior management, is going to screw up their user id and see that they are still able to get into WebFOCUS. I am going to have some 'explaining' to do (which won’t be much because I am not sure how WebFOCUS is doing this).

Is this standard behavior with WebFOCUS on a server?

How can I enforce the login be validated before being allowed to pass through the WebFOCUS gates.

I have a https environment using WebFOCUS version release 7.1.8 (yes, it’s an old release but it has been very stable).

I guess if I am told not to worry about it and remove the sign on page, the pains in my chest will subside.

Hey Harry! Long time no talk.

Well, that is a large entry indeed. Unfortunately, you didn't really put anything in that that could help us help you.

Stick to the basics for now:

Application Server? (What application server is the WF client deployed on)
Split tier? (Is WF client and server on same box)
Are you using a HTTP Server? If so what one?
WF reporting server Security setting? (EDAEXTSEC=___)

Is AD security applied at the server or the WF client or both?

Hi, it has been a long time. Nice to have you respond.

I installed this version over 3 years ago. So, what I did back then and why are a bit sketchy.

Everything is on one Windows box. IBI software and the data. It is a very simple environment. One that I thought would get even more simple after the mainframe connection was dropped.

Configured security is 'PTH' as set by EDAEXTSEC variable. Years ago, I was instructed to set it to PTH by IBI but it was so long ago that I cannot remember why.

In the edaprint.log file, I noticed:

error: OS/security mode does not support IWA security, default to EXPLICIT for HTTP Listener

Before the WebFOCUS login page appears, users have to enter the domain-name\ADS-User-name and password.

I hope this sheds some light...

FOCUS 7.3.4 on Z/OS
WebFOCUS/EDA 7.1.8 self-service - Win2003 and Z/OS

quote:

Before the WebFOCUS login page appears, users have to enter the domain-name\ADS-User-name and password.

Please explain further?

Also, what is the application server that the WF Client Application is installed on? Tomcat, WebSphere ....

Sorry...

Apache Tomcat Version 5.0.28

Since it has been a long time since I have had to do admin work with WebFOCUS, my familiarity with the terms is not what it was. Thank you for you patience and help.

Harry,

It sounds to me like Tomcat is validating the user before you enter the WF web app. If Tomcat is authenticating the user, then that might explain why WF is behaving the way it is.

What parameter are you using for the DBA password setting? Would it be &REMOTE_USER by chance?

Well, if Tomcat is doing the validation, do I need to worry about presenting a login page.

I know I have seen REMOTE_USER in many of the config files. Do you have a file you want me to review in particular?

In my C:\ibi\WebFOCUS71\client71\wfc\etc\SITE.wfs, I have:

_HTML_COMMENT_VAR=CGI gened on &_cgi_gen_var\n

TUEXEC = &TUEXEC
TUEXEC (PASS)

TU = &WF_REMOTE_USER
TU (PASS)

EDALOG = &IBIF_ex
EDALOG (PASS)

TUHTML = &TUHTML
TUHTML (PASS)

TUMR = &IBIMR_proxy_id
TUMR (PASS)

TU is an &variable I use in my STARTUP.fex that initializes the user's environment.



C:\ibi\srv71\wfs\etc\site.wfs

IBIMR_action EQ "MR_SIGNON" and IBIMR_user.upper NE "PUBLIC"
IBIMR_user = &WF_REMOTE_USER
IBIMR_pass =



In my login web page, I use:

IBIC_user
IBIC_pass

For the mainframe, I had a .jsp page (/ibi_apps/temple-racf.jsp) form action "/ibi_apps/WFServlet"

session.setAttribute("mfUser", request.getParameter("IBIC_user"));
session.setAttribute("mfPass", request.getParameter("IBIC_pass"));

name "IBIC_user" value "<%= session.getAttribute["mfUser") %>">
name "IBIC_pass" value "<%= session.getAttribute["mfPass") %>">

I probably don't have to do this anymore and actually forgotten why I had to do it many years ago. Once it worked, I put it out of my thoughts.

FOCUS 7.3.4 on Z/OS
WebFOCUS/EDA 7.1.8 self-service - Win2003 and Z/OS

It appears to me that you do not require your own logon. Tomcat is authenticating for you, and it is setting the WF_REMOTE_USER (user id without the domain) which in turn is driving your DBA.

After I echo'd out my startup and I saw that it was selected in the correct user no matter what I put in, I thought that I was safe (although I did not suspect Tomcat was covering things.

So, as far as security and authentication, would you agree that I am safe?