Hi,
We recently installed v8.1.05, we are trying to use the &WF_REMOTE_USER value in our reporting systems.
We are still running on self service i.e. on EDASERVE.
When we run a report from a dev studio the WF_REMOTE_USER is filling up with our user id(windows authentication) as we login to the dev studio with the same id. when we try to run from the browser with out logging in to WF client then we are getting a blank space.

Can some one help us figure this out.?

thanks in advance,
Kishore.

This message has been edited. Last edited by: <Emily McAllister>,

Kishore,

The &WF_REMOTE_USER gets set by the client. If you are bypassing the client and logging directly into the reporting server it won't get set.

In the help file IBI recommends using the protected reporting server variable &FOCSECUSER. This is meant to replace the older functions of GETUSER and CNCTUSR.

If you absolutely must use the &WF_REMOTE_USER variable, which I wouldn't recommend. You could set &WF_REMOTE_USER in the EDASPROF on the reporting server. I would check for the existence of the variable, and if it doesn't exist then populate it with &FOCSECUSER.

Interesting, I would have expected the user to be "public"

Waz & Eric,
For IBIMR_user we are seeing the value public.
but for WF_REMOTE_USER its a blank.

the below is the site.wfs file we have

HTTP_HEADER_NAME=REMOTE_USER
WFS_VAR_NAME=SM_REMOTE_USER
CopyHTTPHeaderToWFVar (HTTP_HEADER_NAME, WFS_VAR_NAME)

SM_REMOTE_USER EQ ''
HTTP_HEADER_NAME=sm-user
CopyHTTPHeaderToWFVar (HTTP_HEADER_NAME, WFS_VAR_NAME)


HTTP_HEADER_NAME=user-agent
WFS_VAR_NAME=USER_AGENT
CopyHTTPHeaderToWFVar (HTTP_HEADER_NAME, WFS_VAR_NAME)


SM_REMOTE_USER (pass)
WF_REMOTE_USER (pass)
USER_AGENT (pass)
SERVER_NAME (pass)
IBIMR_user (pass)

Thanks,
Kishore.

WebFOCUS 7.6, 7.7, 8.1.05
Windows, All Outputs

From what I understand, to get REMOTE_USER, the webserver needs to get the value, and I think IIS is the only one that will get the user from the network login, all others will have to prompt for user/pass

Waz,
Yes you are correct, and we are using IIS as the web server.
I made sure the Anonymous Authentication is Disabled for IWA.
How ever I will re-confirm if the user id is passing from IIS down stream. and before the URL hits Web focus we have tomcat between.

Thanks,
Kishore.

Waz,
We think the settings on IIS looks good.
do you have any idea where to look at?

thanks in advance,
Kishore

I guess I'm a bit confused here...

If I understand the issue correctly, you are accessing only the Reporting server, and not receiving a value for WF_REMOTE_USER. Correct?

assuming that is correct, why are we even considering IIS since that will server up the client. IIS has nothing to do with the Reporting Server. Neither does tomcat. If in order to "go through" IIS, you need to "go Through" tomcat, then this only occurs when using the client. Since you're not using the client, this will have no impact.

My second question is why would you expect a value that is populated by the client to be populated when you are not using the client? That's not how it works.

So Since IIS does not interact directly through the reporting server but instead from user -> tomcat -> IIS -> client -> Reporting Server and we have established that we are not accessing the client... We are we not looking at other variables which are populated by the reporting server?

As I see it right now, what you are experiencing is expected behavior and you need to write a small script to populate WF_REMOTE_USER on the reporting server in the absence of a client connection. That or use a different variable, which would be my suggestion as long as there isn't to much that needs updating to achieve that.

I think you need to look into some sort of SSO.

Waz,

SSO still won't help when connecting directly to the Reporting Server. SSO goes through the client.

I don't want to confuse the issue, but will using the GETUSER function help in any way?

Documentation > Using Functions > System Functions > GETUSER: Retrieving a User ID

Question: Why are you bypassing client authentication?

IIS is one of those rare pieces of software that can handle Windows authentication. Any other web or application server will have to jump through hoops to do that, which usually involves setting up some kind of LDAP-based authentication module.

If you have IWA working for web access on port 80 (default HTTP port), then it's a simple matter of directing Dev Studio to that port instead of its default port 8080 (which goes straight to the application server, bypassing IIS).

If you do not have IWA working, something in your configuration is not setup correctly. In IIS, you need to have disabled 'Anonymous Authentication' and enabled 'Windows Authentication' on the 'jakarta' virtual directory[1] - that's the one that the ISAPI redirector lives under.

What's also important is to have the IWA 'Providers' ordered correctly, with NTLM first and Negotiate next. I don't know why, that's MS world and I don't understand their logic.


Finally, I remember we had some trouble setting this up on WF 8.1 as well and it turned out that the client's configuration files were not passing IWA on correctly. These files are some new xml files, documentation does not seem to exist. IBI support supposedly knows what they're supposed to contain, they're not exactly self-documenting. IBI support did help us, but whether they can help you depends a bit on the level of knowledge of the rep you get.



Ad 1. You can enable IWA on a higher level, but if you do that, you're also authenticating all your static content, such as HTML pages, images, javascript files, CSS stylesheets, etc. That means 3 HTTP requests for every file (two returning with a HTTP 401 error and the 3rd successful). It slows things down measurably if you have a decent amount of static content to load for each report (we do).

Francis,

GETUSER was actually my first suggestion... To be more accurate, as my suggestion was to use the protected variable &FOCSECUSER because GETUSER is not recommended by IBI according to the help file.

Also as I've been saying this whole thread, I don't know why we continue to talk about IIS and the client when Kishore has clearly stated that they are not accessing the Reporting Server through the client. That alone makes all of this conversation about IIS irrelevant. I'm so utterly confused why people keep insisting about talking about the web server when Kishore explicitly said they aren't using the web server. And to my knowledge, IIS can not directly interface with the Reporting Server. So your two options are this:

1) don't ever run reports that need &WF_REMOTE_USER when logging in bypassing the client

2) set the WF_REMOTE_USER variable in the edasprof. Check for the existence of &WF_REMOTE_USER. If it exists then populate it with that, otherwise us &FOCSECUSER (or GETUSER or CNCTUSER).

quote:

SSO still won't help when connecting directly to the Reporting Server

True, but what other option is there ?

Other options include...

Using the recommended IBI variable for identifying a user (&FOCSECUSER)

Manually setting WF_REMOTE_USER in the edasprof as described above.

Not logging into the reporting server directly. You can get to the reporting server through the client. No need to go direct. End users shouldn't be hitting the client directly, and I thought report caster no longer hits the client directly in 8105, but that also goes through the client.

There are other options. Kishore didn't ask how to get IIS to work with the Reporting Server, he asked how to populate WF_REMOTE_USER when accessing the reporting server. Trying to get the client involved seems like an exercise in futility to me.

I guess if you really wanted to go the more difficult route you could create your own login page that would log you into the client, then launch the reporting server. A lot more work then its worth if you ask me.