WebFOCUS Magnify Search Security

WebFOCUS Magnify is our revolutionary search tool for finding your data across the entire enterprise. It combines the power of our 250-plus data adapters with a powerful search engine – the built-in Lucene or Google – to deliver dynamic results that help you find your data quickly.

Our patented search interface allows you to filter easily through results via dynamic categorization or even perform analysis on your search results with Active Reports. Using the WebFOCUS engine, reports are built dynamically to present the user results in an easy-to-understand format.

This article details the security implemented within WebFOCUS Magnify.

Enterprise search engines range in capacity from 50,000 documents to more than 30 million documents. Such capacities allow for thorough indexes that encompass data from various systems, departments and individuals.

In order to index such data, a search engine is typically given sufficient permissions to this data such that it can either be read directly or fed to the engine. Typical user permissions span only a subset of this. Thus, a search engine has knowledge of more data than a user does.

Security must be implemented to prevent a search engine from delivering privileged data to a user who has no authority to access such data. At the same time, this security must be imple-mented in such a manner as to not impede the benefits of search: finding information quickly.

Types of Security

There are three basic types of security that can be implemented by a search engine returning results to a user. In each case, a user's credentials have been passed to the search engine.

No Filtering (Presentation Security): With this type of security the search engine does not filter results. A search for "John Doe salary" would show a hit for any records that match. The search engine has acknowledged the existence of the document, shown a snippet, and also given the user a pointer to the information.

At this point, the only way to secure the data is to make sure the presentation is denied. Thus, file system permissions and application permissions must prevent the data from being shown when clicked. Only the application or file system enforces security.

This type of security is least desirable.

Filtering: This refers to security in which secure records are hidden from view by an unauthorized user. There are two types of filtering models: static and dynamic.

Static Filtering: In this type of security, the search engine filters records that the user is not eligible to see. This is a vast improvement over the prior security model in that the user is given no knowledge as to the existence of particular documents. Snippets and pointers to the information are also hidden from the user.

The mechanism by which the search engine makes this determination is via an embedded authorization on each record. For example, a sales record may explicitly name users or a group that is eligible to see this document. Thus, the search engine index stores specific permissions to allow or deny a record within the record itself.

An additional problem arises in terms of synchronization. The index must be constantly refreshed to reflect the latest changes in authorization for files and applications. If authorization is not kept in sync, a user may be denied when clicking on a search result. Worse yet, a user may not see search results he is entitled to.

This type of security is better, but inflexible as the only way to change permissions is to reload the record to maintain authorization for users.

Dynamic Filtering: This type of security also allows the search engine to filter records that a user is not eligible to see. The main difference from static filtering is that the authorization for the record is not stored within the record. Instead, authorization is checked on demand as search results are presented to the user. This allows a record's authorization permissions to be changed without re-indexing the record in the search engine.

Each on-demand check can reference an external user repository. This allows for ease of mainte-nance of permissions as well as integration with existing user maintenance.

This type of security is the most flexible and user friendly.

WebFOCUS Magnify Security

Magnify's security model uses dynamic filtering combined with presentation security. This security model is more robust than dynamic filtering alone as pointers to data presentation are also secured.

Practically, this means that an authorized user who sees an eligible record cannot send the link to an unauthorized user and expect it to function. The unauthorized user will be denied the information despite the use of a proper link to data.

In WebFOCUS Magnify, the Managed Reporting user repository is fully leveraged to manage users and assign permissions.

Each named user in Managed Reporting is eligible to view secure documents stored within WebFOCUS Magnify. Unsecured records are available to all users.

Users are granted security via Managed Reporting domains, each of which contains a collection of specific users. Users may exist in one or more domains. This domain model can be used to classify data. For instance:

Sales Domain has access to a client information database, sales reports and CRM application.

Accounting Domain has access to the salary database, pay stub PDFs and P&L Reports

In Form 1, a simple example is shown. Typically, domains reflect a person's role in the organiza-tion. In the case of Bob, we see that he is a member of multiple domains. Thus, he is also eligible to see results from these domains when a search is conducted.

If John queries WebFOCUS Magnify for the salary of a co-worker, he will not see this data in his search results. It will appear to him as if the data simply does not exist.

The specific mechanism is as follows:

1. John logs into WebFOCUS Magnify with his username/password.

2. He conducts a secure search for "salary"

3. WebFOCUS Magnify searches it's index and finds two eligible records
a. Salary demo data (in the sales domain)
b. Company payroll pay stubs (in the accounting domain)

4. Each record is dynamically checked against WebFOCUS via Managed Reporting
a. Salary demo data is OK to show. John is a member of the sales domain.
b. Company payroll pay stubs are not OK to show. John is not a member of the accounting domain.

5. The eligible records are returned to John in the search results.
a. Salary demo data

6. John clicks on the salary demo data record

7. John is authenticated/authorized against WebFOCUS (prevents passing a URL to unprivileged users)

8. A Dynamic WebFOCUS Report is presented to John

Central to all transactions with the user is the WebFOCUS Security layer. It is impossible to access secure data without the authorization of WebFOCUS.

In the event that WebFOCUS is unreachable, least privileged permissions are assumed. Thus, all secured records will be hidden unless WebFOCUS has authenticated and authorized the user.

Not all records need to be authorized against Managed Reporting. Unsecured records are eligible for view by any user and are not checked via the Managed Reporting security mechanism.

When a record is loaded and indexed within WebFOCUS Magnify, it is flagged as either secured or unsecured. Secured records are stored with references to a Managed Reporting domain. Since domains can be dynamically changed on the fly using the Managed Reporting User Administration tool, permissions for search results can be changed instantly.

Thus, using our prior example, John may instantly see payroll stubs instantly in his next search if he is added to the accounting domain in the Managed Reporting User Administration tool.