B.1 Introduction

The Need to Know (NtkDocDisclosure or NTK) component supports customization for these Content Server security areas:

Content security: Changing user access to content items.
Search results: Modifying the display of search results.
Hit list roles: Changing user credentials for query and check-in pages.
Content metadata security: Altering the behavior of metadata changes for content items.
WHERE clause calculation: Modifying use of the WHERE clause in searches.

For example, with standard security, users can only view content for which they have at least Read permission. The Need to Know component can change this in two ways:

All users can be allowed to see content items from specified security groups in a search results list, even though they may not be able to view the metadata or document itself.
Read and Write permission can be expanded or restricted within specified security groups using a query against content metadata and user attributes.

The Need to Know component provides an HTML administration interface to display security configuration status information, enable editing of security configuration values, and enable viewing and testing of Idoc Script for security configuration values.

Note:

Oracle Secure Enterprise Search does not have the ability to understand the Need To Know security rules to map the information into an Oracle Secure Enterprise Search instance. Therefore, any documents using Need to Know can not be configured to be sent to Oracle Secure Enterprise Search.

B.1.1 Features

The Need to Know function is implemented through the following features:

The Need to Know component is applied by security group. You must identify which security groups will use the component. All content in the specified security groups will appear in the search results for all users.
This component provides the option of making all accounts visible, so a user can get a search “hit” on a content item regardless of its account.
The Security Group list on the Search page will show all specified security groups. If accounts are enabled, all accounts will appear in the Accounts list on the Search page.
A new “DocDisclosureQuery” metadata field and new “hit list” role must be created to support the Need to Know function. The hit list role is given read access to all specified security groups.
You can create new user attribute fields or use existing ones in Need to Know queries.
When a document is checked in, a query can be defined in the “DocDisclosureQuery” metadata field. The query conditions can include content metadata and user attributes, and the query results determine access permission to the document. Queries can be entered manually in Idoc Script, or the Disclosure Query Security applet can be used to build the query.
Whenever a user does a search, the hit list role is dynamically applied to the user, giving them read access to all content in the specified security groups. Each content item is then checked for a query in the “DocDisclosureQuery” field, which determines the user's access to that content item.
If the “DocDisclosureQuery” field is empty, standard security applies. Standard security can also be explicitly specified in the query field, or it can be used in a boolean combination with other document and user attributes to expand or refine the read access.
If a query is entered for a content item that is not in an NTK security group, the query does not run, and standard security applies.
If a user already has more than Write or higher access to the security group, the query in the “DocDisclosureQuery” field does not run, and standard security applies.
A global query can be defined for all content, so individual queries do not have to be specified for each content item. You can set up the system to allow the global query to be overridden when a query is entered during check-in.

B.1.2 Applications

This component can be used as the starting point for a more complicated security implementation, such as:

Providing integrated tracking for downloads of sensitive documents.
Controlling Write or higher privileges through custom logic.
Implementing view limits and subscription control, where documents within a certain security group may only be downloaded so many times.
Controlling access by incorporating entries from a custom database table or results from a custom API. This is a hook for externally controlled authorization.