WebFOCUS Newsletter Summer 2004 - ReportCaster Security: How It Works

ReportCaster security often causes confusion because it involves two separate sets of credentials. One set gives access to ReportCaster and the things one can do in it, including scheduling and viewing the Library. The other set gives access to the places where the reports and the data live.

Further complicating this for 4.3.6 users who upgrade to 5.2.x is that until 4.3.6 there was only one set of credentials. The same username and password would get you into ReportCaster and be used as the logon information to the Reporting Server.

And I haven't even begun to discuss the relationship between Managed Reporting authentication and ReportCaster…

Why Two Sets of Credentials

Life was simple in 4.3.6, as uncomplicated as buying a suit off the rack. But this isn't a one-size-fits-all world. In 4.3.6 the ID you logged on with was the same ID you used to fetch your data. Either that or everybody used the same Execution ID.

But not every installation wants to share the IDs between Managed Reporting/ReportCaster and the reporting server. And what about the concept of having multiple reporting servers? Or different data access rights for different reports? Or allowing a programmer to schedule reports for distribution to someone else?

Because of these scenarios, and the need for increased security and flexibility, ReportCaster 5.2.x enables users to have a ReportCaster logon ID to log on to ReportCaster, often called the RCUSER, and a separate ID to get on to the Reporting Server, often called the Execution ID. This allows jobs to be owned by the RCUSER, not the Execution ID, and for the owner to run his jobs with different Reporting Server IDs.

This change in paradigm became particularly sticky for users of the Servlet API, which is designed using the old security model, which is the concept of a shared MR/Reporting Server Execution ID. Although less secure, this was OK in 4.3.6 installations because a temporary user of the same name as the Execution ID was created in the ReportCaster tables if one didn't exist. But 5.2.x doesn't create one on the fly for security reasons. This means that synchronization and/or coding changes are necessary to keep some 4.3.6 Servlet code working after upgrades to 5.2.x.

As a response to this problem, in 5.3 there is a complete User Management API that allows coders to dynamically update BOTUPROF so older Servlet API programs continue to work.

Reporting Server Authentication Choices

With two separate IDs lots of combinations are necessary to support customer needs, and some users are requesting more. Following is a description of ReportCaster/Reporting Server security choices. These settings can be configured uniquely for each individual Reporting Server to which ReportCaster has access.

SHARED: a setting indicating the RCUSER will always be the same as the Reporting Server ID (Execution ID.) As in 4.3.6, the same user names must be in MR/RC and the Reporting Server.

TRUSTED: This indicates that following the initial authentication, ReportCaster will be communicating with the Reporting Server without supplying a password. This is often used as a way to allow schedules to keep on working despite the periodic changing of passwords related to the Execution ID. Trusted only works when the Reporting Server is on UNIX or Mainframe platforms. It doesn't work on Windows because of the design of Windows systems.

RUNID STATIC: ReportCaster always connects to the Reporting Server with the same ID. This is often used for convenience, but it doesn't allow administrators to know who is using reporting resources.

RUNID USER: ReportCaster connects to the Reporting Server with an ID supplied by the user.

ReportCaster Authentication

As you probably know, if ReportCaster is installed with Managed Reporting, all user management takes place through MR. This means that not only are users added and deleted from MR, but the MR basedir and the RC BOTUPROF table must be synched.

This becomes particularly complex if MR is doing its authentication via an exit, meaning the user names are living outside the MR basedir. ReportCaster still needs the users in BOTUPROF in order to assign owner names to schedules, among other things. Since the basedir doesn't have the user names, our standard synch utilities don't help.

In these situations customers must create simultaneous updates to RC within the exit, or run batch jobs to make sure the user names from the system of record are placed in ReportCaster. When ReportCaster isn't installed with Managed Reporting, RC offers its own user administration facility. If the customer wants to authenticate externally, they may do so with the RC exit. However, user names still need to be synched between the system of record and ReportCaster.

Customer Problems and Solutions

OK, so now that we've run through the combinations and given some background, let's take a look at a scenario or two and try to dissect what is happening and how things are supposed to work:

One complicated scenario is a SHARED installation using a Managed Reporting exit that bypasses Web server authentication. For example, let's take a look at this hypothetical customer installation.

For access to ReportCaster, the customer uses an MR exit that authenticates against the system or record, which also contains the Reporting Server IDs. The customer also does a batch synch of these user IDs with ReportCaster. Web server authentication is bypassed.

For ReportCaster Data Server security, the customer uses SHARED + TRUSTED. The Reporting Server is running on USS.

Logically, here's the expected behavior:

The customer logs into MR with his or her normal ID from the system of record. The customer gets in because the exit is working. Life is good. The person clicks on the clock icon and gets into ReportCaster because the user synch placed the names in the ReportCaster repository. Life is still good. The person schedules a job and connects to the Reporting Server. The user ID is hard-coded in ReportCaster because he/she is connecting as SHARED. Entering a password is unnecessary because the person is also TRUSTED and was authenticated when logging in. The person gets the list of FOCEXECs to which he or she has access and chooses one. Life is getting better.

The customer completes the scheduling of the job and waits for it to execute. It fails due to an EDA authentication error. Life's tough again. What happened?

It boils down to the way ReportCaster does TRUSTED authentication. When ReportCaster schedules a TRUSTED job, it needs a user ID to connect to the Reporting Server when the job is run. It takes this from the Web server container (REMOTE_USER) rather than use the owner of the schedule. Our development team designed it this way in anticipation of another type of authentication scheme. However, because this customer is bypassing Web server authentication, the REMOTE_USER variable is null. So when ReportCaster goes to run this FOCEXEC at execution time, it gets an authentication error from the EDASERVER.

In 5.3 this has been fixed with a new flavor of TRUSTED called 'PASS THROUGH.' If the user selects 'PASS THROUGH' when configuring Data Server security, then we pass the owner ID when scheduling a job, and that is used at execution time.

Changing Passwords

Another common problem Windows users have is enabling schedules to continue running properly after Reporting Server passwords change. Since Windows doesn't support the TRUSTED mode, we always need to supply a password. This means that every time an execution ID has its password change on the Reporting Server, there will be an authentication failure until the password is updated in ReportCaster.

Since this is a Windows problem, Information Builders is hobbled in trying to fix this. Outside of moving the Reporting Server to a Linux or UNIX installation, there are two workarounds. The first involves running TRUSTED with the Reporting Server in unsecured mode. This means that authentication will never be required, but the schedule will still always pass a user ID because of the TRUSTED setting, and that user ID will still be associated with the job on the Reporting Server when it runs. Still, there are other potential security concerns with this. So, if this is being considered, you might want to create a separate Reporting Server instance just for ReportCaster jobs or for segmented groups of users.

The second possible solution involves remembering that you don't have to alter the password in all of the schedules when an execution ID password changes. Because Execution IDs are not considered unique to individual users, they are managed globally. That means changing the password in one schedule, or by using our global replace tool, will change the password for all schedules using the same Execution ID.