Managing Search Definition Security

Access the Security page by selecting PeopleTools, Search Framework, Search Designer Activity Guide, Search Definition and selecting the Security tab.

Image: Security page

This example illustrates the fields and controls on the Security page. You can find definitions for the fields and controls later on this page.

Security page

The Security page enables you to restrict access to search results generated by a search definition. Depending on the sensitivity of the search results, you can set these degrees of security:

Field or Control

Definition
No Security

Select to define no security restriction for a search definition's search results. Anyone with access to the application can view the search results for a search definition set to No Security. That is, the search results are public to all users.
Source Level Security

Select to allow or restrict access to the entire search definition as per the specified user or role. That is, only specified users and roles are able to view search results for that search definition.
Document Level Security

Select to restrict access to specific search results (documents) generated by a search definition. That is, with document level security, users can view search results generated by that search definition, but only the documents to which they have access.

Note: This is generally referred to as row-level security in PeopleSoft applications.

Access the source-level security settings by selecting the Source Level Security radio button.

Image: Security page - Source Level Security options

This example illustrates the fields and controls on the Security page - Source Level Security options. You can find definitions for the fields and controls later on this page.

Security page - Source Level Security option

Field or Control

Definition
Type

Select Role or User depending on the scope of your intended access restriction.

Selecting Role restricts access to a specific PeopleSoft role.

Selecting User restricts access to a specific PeopleSoft user.
Name

Select the user or role name.
Privilege

Define the access privilege or restriction.

  • Allow. The specified role or user is allowed to view search results for this search definition.

  • Deny. The specified role or user is not allowed to view search results for this search definition.

Note: Source-level security applies to every document within that search definition for the search engine.

Access the document-level security settings by selecting the Document Level Security radio button. Document-level security can also be thought of as attribute-based security.

With document-level security, one or more PeopleSoft Query columns act as the security attribute. The security attribute is cached on the search engine for each document. Only those users who have the correct security attribute will have the document returned. You can then specify an application class (AppClass) that 'returns a list of security values for the current user. The Appclass is called when the user submits the search request.. When the user submits the search request, the search engine compiles a list of values returned from the application class associated with that specific user to build the security filter.

Image: Security page: Document Level Security option

This example illustrates the fields and controls on the Security page: Document Level Security option. You can find definitions for the fields and controls later on this page.

Security page - Document Level Security option

Document Level

Field or Control

Definition
Query Name

Select the name of the query or connected query containing the fields you want to use to restrict access.
Source Field

Select the field which will identify security values which will determine access.

The source field(s) selected becomes the security attribute having the specified privilege. At indexing time, when the crawler inserts application data into the index, the values populating the selected source field(s) will carry the specified privilege.
Privilege

Define the access privilege or restriction.

  • Allow. The value specified in the Source Field is allowed access to the data for this row in the search results.

  • Deny. The value specified in the Source field cannot see the data for this row in the search results.

Note: The privilege of Deny is useful in situations where there are too many values for the security attribute if Allow were selected. For example, rather than enabling access to nine out of ten field values, it is more efficient to deny access only to the one you want to restrict.

Note: If multiple attributes appear in the grid the system effectively inserts an AND clause between the items in the grid.

Document Filter App Class

The application class specified in the Document Filter App Class section creates a list of values for the specific user performing the query. The application class enables you to define and run additional filters and logic against the application data contained in the indexed source fields.

As needed, PeopleSoft applications will provide filtering App Classes for delivered search definitions. For any custom search definitions, or additional filtering requirements, you will need to create or modify the filtering App Classes.

Field or Control

Definition
Package Name

Select the name of the appropriate App Package.
Path

Select the path pointing to the App Class.
Class ID

Select the class ID for the App Class.

For example, assume you want to compile a list of valid SETIDs to which the user may have access. You define an application package that would contain a method called evaluateAttrValues. This passes the search definition name (sboName), the name of the security attribute field that was identified in the search definition, and the user who will access the data. The application method would then build a list of valid values for that user and return it to search engine for comparison against the data to see if the attribute value on the data matches.

method evaluateAttrValues
   /+ &sboName as String, +/
   /+ &secAttr as String, +/
   /+ &srchUser as String +/
   /+ Returns Array of String +/
   /+ Extends/implements PTSF_SECURITY:SearchAuthnQueryFilter.evaluateAttrValues +/
   Local array of string &secValues;
   Local string &Role, &userPref, &csFullAccess, &csAdminAccess, &OnBehalfOf, 
   &docOwner, &BU_Security, &Security_Type, &SID_Security, &PermList;
   Local SQL &sqlRoles, &sqlUserPrefs, &sqlDocOwners;
   
   &secValues = CreateArrayRept("", 0);
   
      /*&BU_Security, &Security_Type, &SID_Security*/
      SQLExec("Select SETID_SECURITY, SECURITY_TYPE 
      from PS_INSTALLATION_FS ", &SID_Security, 
      &Security_Type);
      If &SID_Security = "N" Then
         &secValues.Push("A:ALL");
      Else
         Evaluate &Security_Type
         When "N"
            &secValues.Push("A:ALL");
         When "O"
            &secValues.Push("U:" | &srchUser);
         When "C"
            SQLExec("Select OPRCLASS from PSOPRDEFN where OPRID = :1", 
            &srchUser, &PermList);
            &secValues.Push("P:" | &PermList);
         End-Evaluate;
      End-If;
End-method;

Note: Concatenating multiple attribute values using a separator, you can achieve an OR clause between attributes. For example, in the this sample "A:ALL" and "U:"|&srchUser are two different attributes merged into a single attribute to achieve the OR clause.

Note: To achieve improved performance, the security attribute should be chosen in such a way that no more than 50 values are returned per user per attribute.