Understanding PeopleSoft CRM Security

Portal Registry

The portal registry is a set of dedicated PeopleSoft database tables that store every content reference, typically a URL, available through the portal. A portal registry has a tree-like structure in which content references are organized, classified, and registered. A portal registry contains folders and content references. Folders group and organize content references into a multilevel hierarchy. Except for the root folder, each folder has a parent folder, and each folder can contain content references as well as other folders. Content references are objects that have been registered in the portal registry.

There are several ways to access and maintain the portal registry:

• Use the registration wizard to register content references, assign security, and update.

• Use the Menu Import feature to upgrade custom menu group definitions.

• Use portal administration pages to add, change, or delete folders and content references from a portal registry.

• Use the portal registry application programming interface (API) for programmatic access to the registry.

• Use the security synchronization process to update the portal registry security based on the menu and script security.

  See PeopleTools: Portal Technology product documentation.

Roles and Permission Lists

Permission lists are the building blocks of user security authorizations. You typically create permission lists before you create user profiles and roles. When defining permission lists, however, consider the roles and user profiles that you will use them with. Recall that roles are intermediary objects between permission lists and users. You use roles to assign permissions to users dynamically. Permission lists may contain any number of permissions, such as sign-in times, page permissions, and component interface permissions. Permission lists are more flexible and scalable when they contain fewer permissions.

Dataset Security

Dataset security controls row-level access to transactions. Dataset security is achieved by associating the definition of a dataset to the search definition for transactions that have multiple dataset rules. PeopleSoft dataset security framework may be used to build dataset rules and assign the dataset rules to PeopleTools roles.

PeopleSoft delivers a set of dataset security rules that may be used to secure transaction rows. PeopleSoft CRM uses dataset security for data searches to restrict transaction rows.

It is also used in these applications and functions:

• PeopleSoft Sales (leads and opportunities).

• PeopleSoft Order Capture (quotes and orders).

• Calendar and Task Management.

• PeopleSoft Marketing (audience and marketing programs).

Business Unit Row-Level Security Options

You can implement security to prevent individual users or roles from accessing specific rows of data that are controlled by key fields. Likewise, you can restrict users so that they can access only a specific subset of rows. For example, you might set the user ID security for a call center agent in Paris so that the agent can access only the data that is for a particular European business unit. If you have a team of call center agents in Paris, you could add them all to a role and then use role security to give them all the same access to the system.

A user can belong to multiple roles and use the menu items that are assigned to all of those roles.

This table describes the consequences of row-level security when you use different combinations of system security options and roles:

You must define the users or roles that have access to specific business units and setIDs. For example, you might give a particular role access to only one business unit. When a user in the role enters prompts for business units (for example, when entering data that has business unit as the primary key), the available selections include only the business units for which the user has been granted authority. The user's available data has been filtered through one or more levels of security.

The number of users that are assigned the same level of security is a key factor in determining whether you base security on user IDs or roles. If a large number of users have identical access requirements, consider using roles. By assigning the users to a single role, you can make subsequent changes to access requirements once rather than many times.

Preferred Markets and Security

The preferred market that is associated with a user ID controls the data and functions that a user can access. Preferred markets are of two types: industry and geographic.

If a user's preferred market is geographic, the user can only access functionality and data that are valid for business units in the geographic region or country. For example, a country might require certain information about imports that users in another country would not need to enter.

If the user's preferred market is by industry, the user is granted access to only the functionality and data that are implemented for those industries.

See:

• Overall Preferences Page

• “Understanding Portal Technology” in Peopletools Portal technology product documentation.

• PeopleTools: Security Administration

Enterprise Administration

Application Security consists of three main pieces: membership lists, view lists and functional options. Using PeopleSoft CRM application security, enterprise administrators have the ability to:

• Define the community of participants for which security is restricted (membership list)

• Define a set of business processes or actions that a participant in the membership group can perform.

CRM Application Security Terminology

This table lists terms related to security:

PeopleSoft CRM Application Security Framework

PeopleSoft CRM application security framework is a characteristic-based security framework that enables PeopleSoft customers to secure data and functions within a transaction.

Use PeopleSoft application security to abstract customers as security objects. The characteristics that define the group of customers are called lists.

You can predefine the objects and lists as either membership or view to differentiate viewers from the target transactions or data objects.

Application security involves setting up and defining:

• Membership lists

  Membership lists define the characteristics of one or a group of users to whom system and data access and functional permissions and privileges are granted. Users in a security membership list definition are associated with a security profile.

• View lists

  View lists define the characteristics of the viewing object (for example, customers or product catalogs) that are secured from the membership list.

• Functional options

  Functional options define the functions (for example, order submission) that can be carried out by members of a membership list.

• Security profiles

  Security profiles define the combination of view lists and functional options that make up a specific profile of view and function access. Security profiles are given to members belonging to a membership list.

This illustration represents a high-level view of a security profile using PeopleSoft CRM Application Security.

Image: Security profile definition

This illustration represents a high-level view of a security profile using PeopleSoft CRM Application Security.

Security Objects

PeopleSoft delivers a number of security objects that you can use to implement security. You should not, however, change them in any way. Any changes that you make to the security objects delivered by PeopleSoft impact the security profiles and the security list tables. PeopleSoft recommends that you limit the number of security objects that you create and are careful how you use them.

PeopleSoft delivers these membership type security objects:

Dynamic and Static Membership Lists

A dynamic membership list is a saved query of characteristics that result in a list of members for a membership list object. The queries are saved using the dynamic criteria definition that is linked to the membership list object.

If the domain type is dynamic, you can edit the membership criteria using the appropriate dynamic criteria definition. You can also view the results of the membership list.

You may associate the membership list to any security profile currently available in the system. Once you associated the membership list with a security profile, that security profile appears in the security profile list for the membership list. When needed, you can remove the association of the membership list to the security profile.

Static membership lists contain a specific list of members that you may associate with any security profile currently available in the system.

Dynamic and Static View Lists

A dynamic view list is a saved query of characteristics that results in a viewable list of objects. You set up a view list object similar to the way you set up a membership list object. After you establish a view list, you may grant one or more view list objects (dynamic or static) to a security profile.

PeopleSoft delivers these View List Security Objects as system data:

Implicit View Lists

A dynamically defined view list can contain a bind variable or a criteria that is not resolved at the time of creation of the query but is resolved at runtime. This is called an implicit view list.

To set up an implicit view list, you must use the Configurable Search Setup - Search Fields page to select the bind variable for the security components and fields that you want to use on the Add View List or Add Membership List pages.

You can modify the Customer Search (RSEC_CUSTOMER_SRCH) component to use bind variables and create implicit view lists.

See Understanding the Configurable Search.

Functional Options

Functional options are defined independently of security objects and domains. Functional options let you determine what a user you can do within an application. For example, you can create functional options that enable users to submit orders or add new customers. To group view lists and functional options, you define a security profile. The security profile is then granted or associated to one or multiple membership lists.

Functional Option Groups

Functional option group is a grouping of functional options, which you can be associated with a security profile. Using functional option groups can make maintaining security profiles easier and more efficient. Enterprise administrators that must make wholesale changes to security profiles can simply change the functional option group associated with the security profiles that must be changed or updated.

Functional Option Codes

Functional options enable the enterprise administrator to define the functions that users can access within a transaction. Functional options codes are evaluated at run time by the transaction that is evaluating the functional option.

PeopleSoft delivers these functional options codes out of the box when you install and implement PeopleSoft CRM:

Functional Options Conflict Resolution

Conflicts can happen due to the granting of the same functional options within a single security profile or multiple security profiles. To resolve conflicts the system uses these rules:

• If one functional option group grants an option and another revokes it, the revoke takes precedence. If the options are not in the same scenario, the option is granted. Revoke is for the functional option itself. (for example, do you have authorization for transfer money). If one functional option group says yes and another no, conflicts are resolved based on how the revoke options are set up.

• For amounts there is a conflict resolution called max amount wins. This means that if one functional option group gives a user access to 2000 USD and another functional option group give a user access to 3000 USD, and the max amount win option is selected, the user gets access to 3000 USD.

Enabling Functional Options

The display template framework enables you to configure functional option security for your pages. By referencing the functional option on a button or field within the display template, the functional option security is enabled.

See Understanding Display Templates.

Business Object Search System Processing

The transaction adapter determines, based on the transaction, what fields appear on the customer information subpage and the criteria definition that defines the advanced search page. The criteria definition determines what criteria fields appear on the advanced search page, how they appear, and the search definitions to invoke.

The search definition determines the roles to search for the criteria fields, the fields that appear in the search results, how the search results appear, and the quick create definition that the user accesses to create a new business object.

For each role that is searched, the search role determines the security that is applied, the relationships for the role, and whether fields appear in the search criteria or results set for the role. The field definitions determine how the search fields appear on the page, the database records that are searched for each field, and how the user can search for the field.

See Adding and Modifying BO Search and Quick Create Definitions.

Catalog Security

Catalogs are a single group of products or services that are marketed and displayed together because they share common criteria. PeopleSoft enables you to define the layout and content of online catalogs for internal and external use. You define the look and feel of catalogs by creating display templates, and then define the contents that you want to organize and present according to your template definitions. You can designate products for inclusion in a catalog either by direct association (using product IDs) or by creating business rules to dynamically build product content based on the selection criteria that you define. Similarly, you can control user access to catalogs by associating a Security Membership List with specific catalogs.

For Order Capture there is a functional option code called SEARCH_ALL_PRODUCTS. When searching for products in Order Capture, this functional option will give users the ability to search for any products that are defined in the system, instead of limiting the search to the products that are defined in a catalog. You must group this option into a functional option group. You would then associate it to a membership list in the security profile.

Security Memberships allow you to specify which users or groups of users can have access to certain catalogs. For example, a company can have a Membership List called All Persons that includes all of the people that have a person record in the system. This Membership List is then associated with a catalog.

This means that all of the people on this list can view this catalog. If a catalog called the Premier Catalog was for Premier Customers, a company can create a Membership List that contains all of their Premier Customers and the Premier Catalog would provide special pricing and recommendations for this group of users.

See Defining Catalog Content and Permissions.

How Security Information is Processed at Runtime

PeopleSoft CRM application security uses several Application Engines and APIs (application programming interfaces) at runtime to help ensure that the customers to whom you have granted security have access to the correct information and customers.

Here are the elements of runtime security that are activated when a user, or customer attempts to access the PeopleSoft CRM applications that you have secured.

• Application Engines

  • RSEC_DAEMON

    Polls for application updates (for example, when a customer is added or updated) and triggers the RSEC_BUILDER

  • RSEC_BUILDER

    Handles the writing of secure objects to list tables.

• Runtime API

  • Determines security memberships and view lists.

  • Generate SQL filters for calling applications

  • Determines functional options, and functional option resolution.

• Definitional API

  Provides application programming interface to add and update security framework metadata.

PeopleCode Application Classes and SQL views provide the API to the security framework. This API is provided for impacted applications to access and update the application security framework. The API is used at runtime to evaluate membership and view privilege result sets, but there are some access methods that are provided to update the framework keys, membership, and view privilege tables directly. The API encapsulates all functionality and structure related to the security framework, so that calling applications do not need to understand the inner workings of the framework.

These access methods are an overview of how each of the impacted applications requirements are satisfied through the API.

• API Based Direct Data Access

  This access method is provided for instances where the membership tables contain all of the relevant data for the calling application. This method produces a result rowset based on the underlying security object definition. In this usage there are three known values and one unknown value. The three known values consist of a membership security object type, a view list object type, and either a membership object ID, and or a view list membership object ID. Based on the ID that is provided, the API determines the security profiles that are associated to the known entity, and from the profiles determines the data that is to be provided as a result set. The API returns this data in a rowset based on the security object’s list record.

• API Based SQL Data Access

  This access method is provided for instances when the results in the membership table need to be merged or joined in a larger SQL statement that is being constructed by the calling application. The known values and the method of data retrieval are the same as the direct data access method, the result of this call is a SQL select statement that returns the keys of the rows of the security object’s table. This SQL statement can be used in a SQL IN clause or correlated sub query to limit the results of the calling application’s constructed query.

• SQL/Query Based Data Access

  There may be instances in which the API cannot be used. An example of this is any time where the logic to determine a result set does not have the ability to run a PeopleCode based API, such as a standard PeopleTools prompt, a view, or a PeopleTools query. For these use cases the design provides example SQL that can be used to join the security data model.

• Functional option Conflict Resolution

  In instances where a key resolves the same functional option multiple times with different properties, the conflict needs to be resolved. Gathering the functional options and privilege overrides is possible using a SQL UNION, but the resolution of the rules is not possible within a single SQL select statement. This requires impacted applications to be in an environment where it is possible to run PeopleCode to determine the applicable functional options. Because of this functional options are not be determined or executed in a view or query type access method.

• Executing Functional Options

  An abstract class/interface is provided to model functional option classes. This class is used by the runtime application to run the functional option logic. The runtime class provides access to the logic that is relevant to the application and coded in the attached application class. The class also provides the ability to access the functional option amount value, operator, base currency, and perform currency conversion if required. The runtime API provide a method to pass multiple functional option codes, and execute them. A calling application’s framework could leverage this to provide data driven execution.

• Update to Data Cache

  Applications that are responsible for the security objects’ secured data require access to update the security cache when a change is made. Since it is possible that a configurable search definition references any data for a given object, all additions and updates to these objects trigger a cache refresh. The known values in this case are the security object type, and security object ID. The API triggers the data caching process providing the known values as parameters. These parameters trigger the caching process to deal only with data that is relevant (for example, the specific object ID).

• Update to Security Framework

  This access method is provided for instances where it is required to update the security framework data directly in a batch or EIP type mode. The API provides access to create membership, view privilege, functional option, and security key objects. The system provides methods to create the associations between the various security objects, and keys. Security Object types (for example, customers) cannot be created through the API. Since there is not a lot of business logic tied to the security setup components, the API uses SQL objects to update the framework tables directly rather than building component interfaces.