How to allow external domain users to access WebFOCUS server instance?

[David Briars]

We currently have authentication to WF set by 'Pre-Authentication'.

We have IIS as our WF web server, with IWA turned on. Our users connect to IIS with a SSO UX, and then are connected to the web client/Apache Tomcat, and then are in wonderful enterprise reporting heaven.

All of our current users are internal, or more to the point, our users and our WF server instance are all on the same domain.

We now have a new requirement to allow users from a external domain to authenticate to WF with a SSO UX.

At the moment, external users see a 'Windows Security' pop up, with the message that 'Authorization required by https://nnnn'.

Any ideas on how to allow external users to access the WF server instance with the SSO UX?

[Martin Yergeau]

Question : must important for your WF env to know which external user has log on ?

Thought : can you, if previous answer is No, redirect/reassign those external users to an authenticated unique internal user which exist in WF ?

But there is probably another option which I am not aware of

[David Briars]

Thank you for your consideration, Martin.

All users coming in from the one external domain, all belong to the same WebFOCUS security group. That is they all access the same reports.

So I guess that means my answer is 'no' to your first question. :-)

So how would I redirect/reassign those external users to an authenticated unique internal WF user?

Is that some sort of AD directive/setting, that can redirect/reassign?

Thanks again.

[Guest]

Hi David

Are both your users using the same SSO UX - like siteminder for example?

Also - I think you should read up on Security zones in the security manual. With those, you should be able to make 2 different authentication zones.

The way WebFOCUS will decide which zone to use will be based on the IP address of the incoming traffic. Would that work?

There's the 'main' zone which maps to securitysettings.xml and then there's the alternate zone which maps to securitysettings-zone.xml.

In each of the zones, you can decide to list IP addresses that identify the zone. Let me give you some pics to get you started. I'd have to get out the manual. We have a blurb about how to use siteminder in the securitysettings.xml (look for requestHeaderPreAuthenticatedPreference and SM_USER for an example). You can decide whether the alternate zone is used for internal folks, or external. A lot of places Alternate for Internal and Main for External people.

Reference security manual: version 9.1 p. 250 Configuring Pre-Authentication With Web Access Management Systems

First some pics

Make sure the alternate zone is enabled in WF client admin console / admin / security :

 

Each zone has a "Request Matching" section:

I haven't been using the URL for pattern matching but that might be easier. In the alternate zone, I'll click on IP Address of the Client / Last Proxy and choose Add to fill in an IP address of my internal folks. First you see a list of allowed IPs:

 

Then you Add ones. Just as an FYI, these ends up in securitysettings-zone.xml.

That might get you started. Make sure the zone is enabled (by default, I think they all are - you might want to turn off a couple).

A very quick summary of what you see in these securitysettings files. At the top, there's the list of things you put a checkmark on from the admin console - let me show you so you don't have to figure out as much about the relationship of the GUI to these files:

Lets look quickly at the top section of the securitysettings files as the starting point. I'll highlight the filterChainEnabled that gets set to "true" when you enable the zone. I'll restate the screenshots from the GUI beneath this:

 

All 4 of the zones start off like this. Think of it as kind of a table of contents and the most basic settings for the zone. This zone will have be Enabled (filterChainEnabled is true).

Also if we go down the list of what authentication filters are enabled (look for "true" next to the name). In this case, I've got

formAuthEnabled as the only thing.

GUI would show:

 

For most of these listed -there will be a corresponding entry a little further down in the file with options for the various filters. For example, since you're using IIS/IWA right now, you would probably see j2eePreAuthFilterEnabled="true" at the top, and when you scroll down a little, you'll see :

Those are options for j2eepreauth...

You will likely end up following the manual section about siteminder (you can search for siteminder in the security manual to find these). Even though the manual is talking about siteminder, other SSO vendors would work fine - you just have to change the SM_USER to whatever Web Access Method's user ID you'll be using. Here's a clip from the manual:

As always I'm rambling. Give that a shot. It might be good to take a backup copy of your securitysettings*.* before you begin so you can do some comparisons to see what's going on.

Last thought that just popped in my head - how do you know what's going on? That'll probably be in your websecurity.log file. You can crank up the logging to show more information from the Admin Console / Diagnostics / logs ... I think there are 2 things that might be of interest to you.

To see some info about your AD connection, you might search the page for com.ibilog. I used to find this log helpful for authentication / authorization (it's in the event.log section).

To debug what's going on in the login process, scroll down to the websecurity.log and crank up com.ibi.webapp.security to TRACE or DEBUG. Feel free to turn on more if you want. There's a button at the top to reset all trace levels to the default settings.

Happy hunting!

Toby

[David Briars]

Toby, this is an excellent summary and pointers into the information we need to review and think upon.

Many thanks.

Dave

[Debra Waybright]

In case it helps, we use OKTA as our SSO and all external users are assigned an ID with LDAP security group and have WebFOCUS assigned in OKTA. They authenticate to OKTA then it passes them on to WebFOCUS. We use the LDAP group to limit what they have access to in WF.

[David Briars]

Thank you Debra.

It is very helpful to me to know how other TIBCO/WebFOCUS clients handled this scenario.

I took a look at the okta product website just now, and can see how this app would work.

Again, many thanks,

Dave