Tightening Up Managed Reporting Security in 7.6.4

By Jim Thorstad

Can one customer’s feature be another’s security hole? Could we have made a mistake with our recommendations for closing that hole? Is it possible to clean this up in WebFOCUS 7.6.4 and introduce a nice new feature at the same time? The answer to all of these questions is of course is yes.
Let’s begin with a quick review of the Managed Reporting (MR) security model. Reports and report library content are created in what we call an MR domain. User access to a domain is controlled by which MR groups the user belongs to. Once we know who the user is we can determine which groups he or she belongs to and finally which domains are associated with those groups. Using security terminology, we authenticate the user and then we determine if the user is authorized to perform a particular action.
We provide several ways for users to access our secured content, including the MR Domains (Java applet) environment, Business Intelligence Dashboard, and Developer Studio. We also offer an optional MR Web services API.
But some customers wanted to expose a subset of their MR reports to large groups of casual reporting users. This presented them with two problems: their administrators didn’t want to create MR accounts for this large and transient set of users, and the users didn’t need (or want) to use our full-featured interfaces. What these customers asked for was a way to allow unauthenticated user access to some of their MR reports. These requirements led to a variation of the MR publish feature, which we’ll discuss next.
When you select Publish from the context menu of a Standard Report you are presented with a dialog that helps you build a launch page for the report. On this dialog there is a checkbox labeled Show as Report which is unchecked by default, as shown on Screen 1.
When the box is checked, the launch page is created as a standard report in the same domain where its associated report resides. When the box is left unchecked, the launch page is created outside of Managed Reporting (under the /ibi_html/publish directory by default) and includes a hidden setting, IBIMR_drill=RUNNID. The hidden setting tells WebFOCUS to process the report request without MR authentication.
There is another variation of the security hole that comes into play with drill-down reporting. When a developer uses our tools to create a drill-down report, they can select child reports in the same domain or any other domain they have access to. Thus you can have report1 in Domain 01 call report2 in Domain 02. WebFOCUS builds the following syntax dynamically when the parent report is run and places it into each drill-down link:
IBIMR_drill=X,domain01/domain01.htm,domain02/app/report2.fex
To support this kind of reporting in the unauthenticated scenario, we chose to bypass the authentication and authorization checks for requests that include IBIMR_drill=X. A consequence of this decision is that the security hole now extends to authenticated user sessions as well.
To illustrate the expanded hole, consider “Bob,” who has access to Domain 01 only. He runs report1 and clicks a drill-down link to report2. WebFOCUS bypasses the authorization check on report2 as we discussed previously and Bob gets this report. Note that Bob doesn’t have access to Domain 02. In fact Domain 02 doesn’t even show up on his domain tree in Dashboard—yet  he can run the report in Domain 02 because his request included the IBIMR_drill=X setting.
So that describes our current situation. We have two settings that tell WebFOCUS to bypass authentication and authorization. This behavior may address the requirements of some customers but it is clearly a concern for other customers who want all their MR content protected by our security model.
Two New Security Features in 7.6.4
The first feature we are introducing in 7.6.4 addresses the security holes described above. It’s a new setting called:
MR_ANONYMOUS_RUN_ACCESS=YES|NO
This setting allows a WebFOCUS Administrator to explicitly grant or deny unauthenticated access to their MR content. The default setting is YES to preserve backward compatibility with previously created launch pages and custom applications. Customers who consider unauthenticated access to be a security hole should immediately change the setting to NO. You can find the setting in the 7.6.4 WebFOCUS Administration Console under
Configuration > Client Settings > Managed Reporting.
When set to NO, all unauthenticated MR report request (even published launch pages and drill-down links containing the IBIMR_drill settings) will be presented with the error page “Cannot execute the request. Please logon to Managed Reporting.” There is one exception to this and that leads me to the second new feature:
MR_AUTOSIGNON=YES|NO
This setting controls whether WebFOCUS returns the error “Cannot execute the request. Please logon to Managed Reporting” or the MR logon page when an unauthenticated user runs an MR report request. The default setting is NO to preserve backward compatibility.
By combining MR_ANONYMOUS_RUN_ACCESS=NO and MR_AUTOSIGNON=YES you can achieve a reasonable balance between good security practices and expanded access to your MR content. You’ll need to create MR accounts for these users, however. In this scenario, users can continue to access MR reports outside of our standard interfaces but upon their first access to MR content they’ll be presented with the MR logon page. After logging in, WebFOCUS will automatically re-run their request and they’ll get their report.
At this point they will have an MR session so if they drill-down to another MR report they won’t be prompted to log in again. Additionally, WebFOCUS will authorize the drill-down request, ensuring that the authenticated user has access to the domains where each report resides.
Documentation Correction
In the WebFOCUS Security and Administration manual, we introduced a chapter called Protecting Your WebFOCUS Installation. In this chapter there is a topic that explains how to Disable Self-Service Access to managed Reporting Reports. We discuss the publish feature and how you can disable anonymous access to MR reports by “setting the protect option on IBIMR_drill,” which requires you to place the following command in your ibidir.wfs file:
<set> IBIMR_drill(protect)
Unfortunately, this command tells WebFOCUS not to accept any request that includes IBIMR_drill in the query string. That means that not only are launch pages run from outside of MR blocked but drill-down reporting (even for authenticated Dashboard users) is also blocked. We didn’t realize this until recently and so the erroneous procedure will be replaced by information about the new MR_ANONYMOUS_RUN_ACCESS setting.
We are introducing these two new optional settings now in 7.6.4 to be responsive to our customers, while avoiding changes in behavior that could affect our customer’s production applications. In the future we will likely change how anonymous access to MR content is processed. For example, we may create the concept of an “MR Guest” account. Customers could assign the guest account execute access to some of their MR reports, but not others. The new 7.6.4 setting doesn’t offer this level of flexibility. Customers with extremely tight security requirements would be able to disable the guest ensuring that anonymous access is denied, regardless of the access rights assigned to their MR content.
If you have comments on this topic or related issues, please let me know.