In our WF7 servers we have a couple of entries in our site.wfs (client-)file to obtain the current username passed in through IIS's IWA, like so:

#retrieve intranet user format: domain\user
USER_ID=&REMOTE_USER
<SET> USER_ID (PASS)
#retrieve intranet user format: user
UID=&WF_REMOTE_USER
<SET> UID (PASS)

However, in WF8 this no longer seems to work and I even seem to recall reading somewhere that IBI deemed this too complicated and no longer supports doing this from the site.wfs. So apparently the new method should be dead simple, but we can't seem to figure this out...

How is this done with WF8?

I verified that user credentials are being passed on from IIS(7) to Tomcat(7), as I can see them in both their access logs.
I changed the settings for the connection between the WF client and server too, as mentioned in http://forums.informationbuild...217024436#8217024436

However, neither the output of our own variables (&USER_ID and &UID from above) nor the output of &FOCSECUSER contain our user names. They are 'null' and 'null' or an empty value respectively.

Hi Wep,
So you are configuring server for SSO? If I remember correctly you should also change securitysettings.xml in /config folder. Allow preauthentication (might be also the j2eepreauth) and change "principalRequestHeader" to "REMOTE_USER".

As I didnt find documentation about that from ECL I might be wrong aswell here, its been while I have setup SSO.

Regards,

That did the trick! Perhaps I changed a few values too many, but now it works

I enabled both of these:

		<property name="preAuthEnabled" value="true"/>
		<property name="j2eePreAuthFilterEnabled" value="true"/>

And changed this bit (original value commented):

<!-- Default:		<property name="principalRequestHeader" value="SM_USER"/> -->
		<property name="principalRequestHeader" value="REMOTE_USER"/>

Apparently IBI thought this wasn't complicated enough yet :P

One difference; our &USER_ID now no longer contains the domain prefix, but we weren't really using that variable anywhere anyway, I think.

This message has been edited. Last edited by: Wep5622,

Okay, there's one big BUT with this approach: it now also uses single signon for the client administration console login! Can that be disabled somehow?

Hmm, noone has had never such request. Your problem now is that you dont have access to administrator console?

One thing I can think of is to use alternative provider too. I can look into the settings files tomorrow. But maybe if you look at the securitysetting-zone xml I dont remember if it was possible to add url to where the request went and then alternative provider was called.

I do have access to the admin console, but with the wrong privileges: mine instead of the admin's.

Why would anybody want single signon to the admin console?

Progress!

Just don't change the principalRequestHeader property away from the default (SM_USER) and you both get SSO for the self-service environment as well as a login prompt for the client admin console.

There's only a slight issue still; while you're logged into the the client admin console as admin, you're admin in your reports as well. Logging out resets your credentials back to your own though.

In our case that means we shouldn't test any reports while we're still logged in as admin from the same browser(-session). Workarounds are easy, for example use a different browser for the admin console, or log into it from a different machine or log out of the admin console.

Oh, this is good to hear and this post will go into my notes for future.

Thanks Wep!