Security Options for Connecting with Reporting Server in 7.6.1
By Jim Thorstad

There is an important new security feature coming in the WebFOCUS 7.6.1 release to which I want to draw your attention. Actually, it’s a collection of new security features created by the programmers responsible for the WebFOCUS Client, Connector and Reporting Server components.
From the 7.6.1 WebFOCUS Administration Console it appears to be only a small change to the Remote Services panel, as shown in Screen 1 below:

Where there once was an option to specify a user ID and password for connections to this Reporting Server, there is now a dropdown list labeled “Security.” But when you click on the dropdown list, you find several new security options:
Service Account – uses the fixed user ID and password you specify for all connections to the Reporting Server.
HTTP Basic – uses the ID and password found for each user in their HTTP authorization header to connect with the Reporting Server. This option requires the Web server be configured for Basic Web authentication.
Trusted – uses the ID found in either an HTTP request header or a WebFOCUS script variable to connect trusted to the Reporting Server. This option is explained in more detail below.
SAP Ticket – passes the SAP single sign-on cookie (MYSAPSSO2) to the Reporting Server for use when connecting to SAP data sources. This option requires the Reporting Server be started in security DBMS mode.
Kerberos – uses the native Kerberos implementation found in Microsoft Active Directory to create a Windows-based single sign-on environment from the desktop to WebFOCUS to the Reporting Server and to many popular databases. There is more on this option below.
Default – this option preserves previous behavior. We’ll discuss this in more detail before continuing with the other options.
One decision we made during the implementation of this feature was that the setting chosen cannot overriden. What this means is that if you pick HTTP Basic but failed to enable security on your web server, you will get a runtime error pointing to the configuration problem; you will not be allowed to log on to the server interactively at that point. Similarly, we do not allow you to preemptively log on to a Reporting Server (with the WF_SIGNON action) that has one of the Security options selected from the dropdown list.

This might appear to present behavior change with regard to the new Service Account option. If you pick Service Account and then enter the password incorrectly by accident, you will get a runtime error when accessing this server. In the past, if you supplied invalid credentials for IBI_REPORT_USER and IBI_REPORT_PASS in a WebFOCUS Client Node Profile the server, would return the authentication error and you would be presented with the server logon page at runtime where you could supply any valid credentials you know.
We decided not to allow this “magic” behavior where you say you want “X” but we allow either “X” or “Y” depending on whether or not you configured X properly. It may be that we find customers would like a checkbox labeled “Allow Override” so that the Service Account setting could be treated as a soft default instead of a hard set. You can still get the behavior you used to have if you select Security = Default (instead of Service Account) and make the settings described above.
New Support for Kerberos
The Kerberos option is very powerful. It gives us the Integrated Windows Authentication (IWA) single sign-on and impersonation support that we’ve had with our WebFOCUS CGI/ISAPI implementation for years, but which we lost with WFServlet.

It turns out the Java world simply doesn’t allow us to propagate the user’s NTLM credentials. But the old CGI/ISAPI NTLM solution had its limitations: It didn’t work with Firefox browsers and suffered from what is known as the “two-hop” problem. This problem is acknowledged in Microsoft’s own documentation and in effect meant that WebFOCUS, the Reporting Server, and the database all had to be on the same machine, which was unrealistic.
Fortunately, IWA supports two protocols: NTLM and Kerberos, which are wrapped in a protocol called Negotiate. Depending on your browser settings, web server and operating system releases, among other things, your browser and the Web server will “negotiate” which protocol to use. In 2007 it’s pretty much a given that the decision made will be to use Kerberos as it was built-in to Windows 2000 and above and is the default preference now in Internet Explorer 6 and above.
Kerberos support is now built-in to the Windows Reporting Server, including its Web console listener, TCP (including deferred service) listener, and the pass-through server used to access its Web console through firewalls. All you need to do on the 7.6.1 Windows Reporting Server to support Kerberos is start it in security OPSYS mode. There is a servlet filter to configure to enable Kerberos support in WebFOCUS and the ReportCaster Web applications. You can learn more about the 7.6.1 Kerberos option in Technical Memo 4647.
New Trusted Options
The final drop-down list option I’ll discuss is the new Trusted option. This is useful in cases when the Web-tier doesn’t have the user’s password; for example when SiteMinder (or any SSO product) is protecting WebFOCUS and you configure MR Authentication = TRUSTED. In this case you can select Trusted from the drop-down list, then pick “HTTP Header” and type in the name of the header containing the authenticated user ID, such as sm_user for SiteMinder). You can also specify a WebFOCUS script variable if it will have the ID you want in it.
The new Trusted option works in conjunction with a couple of changes on the Reporting Server. Previously, the server only accepted trusted connections when started in OPSYS mode and the ID was found on the server’s operating system.
The new Trusted option is now supported when the server is started in security LDAP and PTH modes, provided that the new server setting trust_ext=Y is configured in the server console. A check is made to verify that the user exists in LDAP if the server is started in security LDAP mode.
That’s a summary of the new Security options for connecting with the Reporting Server in 7.6.1. We are beginning to see requirements for two or more security modes to be supported for a single server node, and we are working out a plan to address that in the product. In the meantime, let your support representative know how we can help you solve your security challenges.