Managing Search Definition Security
Access the Security page by selecting PeopleTools, Search Framework, Search Designer Activity Guide, Search Definition and selecting the Security tab.
This example illustrates the fields and controls on the Security page. You can find definitions for the fields and controls later on this 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 |
Description |
|---|---|
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.
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.
Field or Control |
Description |
|---|---|
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.
|
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.
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.
Document Level
Field or Control |
Description |
|---|---|
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.
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 |
Description |
|---|---|
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.