Implementing Single Signon in WebFOCUS

By Jim Thorstad

This year Information Builders has seen a dramatic increase in the number of customers approaching us for help with WebFOCUS single signon implementations. While the Business Intelligence Products Group (BIPG) has been working quietly with customers on single signon for many years, the increase signals that enterprise adoption of WebFOCUS is now moving into the mainstream.

In anticipation of this shift, BIPG has been ramping up its research and development activities. This article addresses these initiatives and the schedule of WebFOCUS Version 5 Release 2.x single signon deliverables rolling out over the next two months.

The benefits of single signon to our customers are obvious: Users are relieved of remembering numerous IDs and passwords while systems people can more easily manage and monitor user activity throughout their systems. But there is no "single" single signon solution out there to discuss; the solution is a function of each organization�s collection of existing systems, policies and objectives. The good news is that we are seeing patterns emerge that make it easier to describe and select the appropriate solution for each case.

Note: The MR Signon Integration topic found in the WebFOCUS Security & Adminsitration Guide (Version 5 Release 2.1) is incomplete and will be replaced by Tech Memos 4517 and 4518, due out shortly. Contact Customer Support for more information.

The Two "Auths"

Before proceeding, you need to come to grips with the difference between authentication and authorization. Authentication is the process that identifies a user or program. Familiar authentication features include basic Web server authentication, Integrated Windows Authentication (IWA), your logon to a Unix/Windows/mainframe system, and our Business Intelligence Dashboard (BID) logon page.

Authorization is the process of managing the capabilities or entitlements for an identified user or program. For example, which Managed Reporting domains can the BID user access? Can the user create and save My Reports? Single signon always involves authentication but it may or may not involve authorization.

The balance of this article is geared specifically to Managed Reporting implementations, as opposed to the so-called self-service type, because this is what we are most often asked about. Once we exclude self-service, Managed Reporting (MR) becomes the central authentication/authorization issue in Developer Studio, BID, and ReportCaster. That is because the MR user ID (IBIMR_user) is simultaneously the MR, BID and ReportCaster owner ID, and the user�s entitlements are based on this ID.

When you consider single signon, the question becomes, To what external user directory out there in the enterprise do you want to bind Managed Reporting?

Web Server Signon Integration

Tech Memo 4517 (MR-Web integration) will show you how to configure our products to bind the MR/BID/ReportCaster ID to the user�s Web server ID. This is fully functional in WebFOCUS Client 5.2.2 Service Pack 9, though to a lesser degree support also exists in earlier service packs and in 5.2.1. In Developer Studio you set Web credentials and leave the MR/RC credentials blank. In ReportCaster you set Remote Authenticated = yes and configure its HTTP User ID and password settings. For BID and MR there are new logon pages that automatically submit themselves. (The user never sees them.)

We are creating a download Zip file with these new pages and the site.wfs file modifications required for MR-Web integration.

Signon Integration With the Reporting Server

Tech Memo 4518 (MR-WFRS integration) will show you how to use the Reporting Server for authentication and bind our MR/BID/ReportCaster IDs to this Reporting Server ID. This approach is helpful when you have access to a user directory on the Reporting Server but not on the Web tier (or when the Web server must run Allow Anonymous for some other reason).

By placing certain commands in the site.wfs file, you configure which Reporting Server (if you have more than one) is the authentication server. Users then use our standard logon pages for MR and/or BID, except that the ID you enter on these pages will be your Reporting Server ID.

Netegrity SiteMinder Compatibility and Signon Integration

Another hot topic is signon integration with third-party packages such as Netegrity SiteMinder. We recently joined the Netegrity ISV program and brought their software in house for testing.

SiteMinder is a powerful set of tools for creating an enterprise single signon solution that can encompass all web-based applications. SiteMinder can be configured to protect some or all of the resources on some or all of the Web and Application servers in an enterprise. Users who access a protected resource and who have not yet been authenticated by SiteMinder are first challenged for credentials. Then, an authorization check is made before the users are allowed to proceed. SiteMinder works by setting an encrypted session cookie that must be passed up with each request.

We discovered problems with BI Dashboard and some of our JSP-based tools, such as HTML Report Assist, when configured in a SiteMinder implementation. We are fixing these issues in the 5.2.2 track. We are also researching how products like Developer Studio and ReportCaster Distribution Server can be supported with SiteMinder. Once these issues are resolved, signon integration with SiteMinder is straightforward. You simply configure SiteMinder to pass us the authenticated ID in the REMOTE_USER variable and follow the steps outlined in Tech Memo 4517 for MR-Web signon integration.

The content in these Technical Memos will replace the incomplete treatment of MR signon integration found in the 5.2.1 WebFOCUS Security & Administration Guide, and this content will then be rolled into the 5.2.3 edition. In each scenario, you use our standard User Administration tool to create users in the MR Repository with no passwords (because authentication is taking place elsewhere) which avoids two problems: There is no MR password expiration feature (a requirement of many company security policies) and users no longer have the problem of their MR password losing synchronization with their other enterprise passwords. If this sounds like what you need, stop here and watch for an announcement on the availability of these Tech Memos. But if you plan on having more than a few hundred MR users, you had better grab another cup of coffee and read on!

External Authorization

Consider for the moment an organization that plans to have 5,000 MR users. Let�s assume that 4,500 of these will be "run only" users who may want to personalize their BID view. The remaining 500 may want to create their own reports from time to time and a small subset of these users are actually developers creating content used by everyone else. There are three MR administrators who also serve the role of RC administrators. Imagine that each week a few people leave the company, a few join, and some number change organizations or privilege levels. Given the choice, no one wants to key these changes into our User Administrator tool. Most large companies already have existing business processes in place to process changes like this and they would like to have those processes automatically drive the authorization in our products. We tell Managed Reporting to derive the user�s authorizations programmatically through the MR Exit. When we do this it is called External Managed Reporting Authorization.

When using the WFServlet option in Version 5 Release 2.x, the MR Exit is a compiled Java� program written to our published interface. This program overrides our standard behavior of looking in the basedir/user.htm file for information needed to authenticate and authorize users. In fact, this file is not typically maintained when an MR Exit is implemented. There are two types of external authorization exits: The type in which the user entitlements are "passed in" to the exit and the type in which the exit calls out to get the user entitlements.

BIPG is developing standardized deliverables (compiled exit, source code, and documentation) for each of these approaches that will be supported at the 5.2.2 level. Stay tuned for an announcement shortly.