Single Sign-On: The Holy Grail of Security

By Diane Sklar

Whenever I get the message that goes something like, "Your password will expire in five days," I sigh. It means I have to come up with a new one. I try to keep them all consistent, and most of them are the same across all the platforms we access as product managers at Information Builders.

But they expire at different times. As one password is phased in and another phased out, I have to remember which systems are on the new password and which are on the old one. And then there’s the question of what to set the password to – something that I will remember and no one else will guess. I’ve already been through all of my favorite ballplayers past and present, European soccer players, family members and pet names, words of inner wisdom and peace, and the whole McDonald’s menu.

Security is always a trade-off between user convenience and safety. But many organizations are opting for a single sign-on environment where the user is only prompted once for credentials and those credentials are passed along to all the applications a user enters during a session. WebFOCUS fits nicely into an environment structured in this way. Of course once an organization decides to pursue the single sign-on Holy Grail, many decisions still must be made. First and foremost, the organization must decide where user credentials will be stored and at what point in processing they will be requested and validated. Storage options abound – LDAP directory, RDBMS tables and operating system user repository, to name a few.

Organizations have different requirements about when to prompt users for credentials as well. Some companies want to prompt when the user tries to open the corporate portal via a secured or unsecured Web server. Others want to prompt when users enter Information Builders’ Managed Reporting environment. Still others want all validation to take place on the data platform where a robust tool like RAC-F might exist.

The Business Intelligence Products Division has formed a special swat team to work with our product support division on certifying and advising on customized security landscapes. Tech memos have been written to document product behavior in various environments. Each time the WebFOCUS Security and Administration Manual is updated, all certified security configurations are incorporated into it. To date, the WebFOCUS Web security scenarios, shown in the chart below, have been documented.

Scenario	Credentials Stored	Point of Validation	Location of Documentation
Basic Web server authentication	Varies: Web server operating system, LDAP, Active Directory, third-party or custom sign-on solution	Web server	Chapter 5, Security Guide (January update)
WebFOCUS Reporting Server authentication	Reporting server operating system	When user submits form to managed reporting environment	Technical Memo 4518 and WebFOCUS Security and Administration Manual Version 5 Release 2.3 (specify DN4500509.0104)
LDAP standalone and LDAP installation wizards	LDAP directory on any platform	When user submits form to managed reporting environment	LDAP standalone wizard – Technical Memo 4524: Configuring WebFOCUS for LDAP Authentication LDAP installation wizard – WebFOCUS and ReportCaster Installation and Configuration manual (titled by platform, e.g., "for Windows")
IWA authentication	Windows operating system platform(s)	At logon to workstation	Soon-to-be-released Technical Memo 4525 (search i-Base using "Technical Memo 4525")

Latest Developments

A few words about some of the latest developments in WebFOCUS integrated sign-on techniques:

IWA is the newest of the techniques to be documented. Quality Assurance on this technique is now in the final stages at Information Builders’ lab.

IWA is the only technique in the list that requires only one sign-on. The other scenarios probably require a sign-on to the workstation when the operating system session starts up and then another sign-on to get into the single sign-on world of user applications. But the IWA scenario uses the workstation sign-on as the entrée into the Web application world.

IWA is a proprietary Microsoft authentication scheme that works via the passing of authentication tokens among Microsoft components only, including various flavors of the Windows operating system, the Internet Information Services Web server and, sometimes, the SQL Server database. Not all WebFOCUS components currently can be run in this proprietary environment, which, unlike WebFOCUS, is non-J2EE compliant. However, Tech Memo 4525 describes how to set up parallel Web sites, one with and one without IWA settings, so that all WebFOCUS components can coexist. No worries about duplicate user, report or schedule administration, though. Both sides of the IWA equation can share the same repositories.

Meanwhile, in other news about the integration techniques I’ve listed, be aware that a new, optional WebFOCUS exit has been written by Information Builders and packaged with WebFOCUS 5.2.3 and higher. This Java™-based exit has three callable methods that enable single sign-on scenarios to be implemented. The new methods are documented in the January 2004 editon of the WebFOCUS Security and Administration Manual Version 5 Release 2.3. They are as follows:

	CopyHTTPHeaderToWFVar – retrieves a variable value from the HTTP Header and places it into the WebFOCUS variable table.
	CopyWFVarToSessionVar – retrieves a variable from the WebFOCUS variable table and places it into the HTTP session.
	CopySessionVarToWFVar Method – retrieves a value from the HTTP session and makes it available for a connection to the WebFOCUS Servlet.

The CopySessionVarToWFVarr and CopyWFVarToSessionVarr methods are used with the Reporting Server Authentication scenario and make the credentials validated by the Reporting Server at the beginning of the user’s session available on every connection between the WebFOCUS client and WebFOCUS Reporting Server. The CopyHTTPHeaderToWFVar method can be used to integrate WebFOCUS with third-party single sign-on products, such as Netegrity’s SiteMinder. Generally, these products have a Web agent plugged in to the Web server, which adds an HTTP header containing the validated user ID to the request before it reaches WebFOCUS. Chapter 5 of the Security Guide talks about how to capture this ID and the limitations to this approach. The new methods in the WebFOCUS callable exit are available for passing other information, such as a user’s business unit or cost center code. Mull over how these routines might help you with custom application needs.

So that’s the news on WebFOCUS Security. Stay tuned next issue for updates on new projects such as WebFOCUS SiteMinder integration.