PeopleTools Security
来源:互联网 发布:mac double gleam 编辑:程序博客网 时间:2024/05/16 18:48
PeopleTools Security
A summary of the main PeopleTools security records.
Operators
Record
Description
PSOPRDEFN
Stores all operators (users) in the PeopleSoft system. Also stores their employee ID (EMPLID), encrypted password, primary permission list, default navigator home page, process profile permission list and row security permission list.
PSROLEUSER
The highest level of security access is defined by roles (think of them as groups). This table stores the roles the user belongs to.
PSOPRCLS
Roles link together permission lists which are the security objects that define access to components, pages, and other areas of the system. This view returns the permission lists that a user has access to via their roles. Note that prior to PeopleTools 8, permission lists were synonymous with classes and most of the security tables still use this convention.
PSOPRALIAS
Aliases can be mapped to a particular operator ID (user). The obvious alias is employee ID (EMPLID) but others include external organisation ID (EXT_ORG_ID) and customer ID (CUST_ID). All ways of referring to the same entity.
PSOPRALIASTYPE
This is the setup table for operator aliases
PSOPRALIASFIELD
This is the setup table that maps operator aliases to records & fields
PSUSERATTR
User attributes store the a hint password question & response for a user (if this is enabled)
PSUSEREMAIL
Email addresses for users.
Roles
Record
Description
PSROLEDEFN
Stores roles and their properties. Roles can be assigned dynamically through Query, PeopleCode or LDAP. Roles are also used in conjunction with Workflow and routing.
PSROLECLASS
Roles are made of up of one or permission lists, and this table links the two together. Very handy.
Permission Lists
Record
Description
PSCLASSDEFN
Permission lists are where the security really happens. They provide access to menus, components and pages and a host of other security including PeopleTools, Process security, Component Interfaces, Web Libraries, Web Services, Personalisations, Query and Mass Change.
PSAUTHITEM
The link between permission lists and menus
PSAUTHBUSCOMP
The link between permission lists and component interfaces and their methods
PSAUTHOPTN
The link between permission lists and personalisations
PSAUTHPRCS
The link between permission lists and process groups
PSAUTHSIGNON
The link between permission lists and signon times
PSAUTHWEBLIBVW
A view linking permission lists and access to web libraries (really just Menus in PSAUTHITEM that begin with WEBLIB_).
PSAUTHWS
The link between permission lists and web services (service operations)
PS_SCRTY_ACC_GRP
The link between permission lists, trees and query access groups
PS_MC_OPR_SECURITY
The link between permission lists and mass change templates. This is an odd table, it uses the field OPRID but really it links permission lists
Check out this forum post for details about how to check which users have access to PeopleTools.
Portal
The PeopleSoft Enterprise Portal basically refers to the navigation system that links menus and components to the PeopleSoft online interface, navigation and search functionality. Access to anything in the online application is handled through portal security. The records associated with this include:
Record
Description
PSPRSMDEFN
Stores the structure of the portal registry. This data is stored in a hierarchical (tree) structure within the table. The field PORTAL_URI_SEG1 is the menu, PORTAL_URI_SEG2 is the component, and PORTAL_URI_SEG3 is the market.
PSPRSMPERM
Stores permission lists associated with access to everything within the portal registry
Useful Queries
Find out which users (and from what permission lists) have access to a particular page:
select distinct OPRID, OPRCLASS
from PSOPRCLS
where OPRCLASS in (
select distinct CLASSID
from sysadm.PSAUTHITEM
where PNLITEMNAME = '<PAGENAME>'
);
To get your mind around PeopleSoft security, it it helps to look at the hierarchy for PeopleSoft security.
Fom top-to-bottom (highest to lowest level of granularity) you can look at security like this:
Portal Security
Menu Security
Roles
Permission Lists and Definition Security
Primary Permission Lists
Row Level Security (user & permission list based)
To explain further:
Portal folders (containers in the left navgiation) are secured by permission lists at the portal level
Portal content references (links on the left navigation) are based on menu security
Roles give users access to one or more permission lists
Permission lists give users access to menus, components and ultimately pages
Definition security is used by application designer to secure definitions (e.g. fields, records, pages, components)
Primary permission lists typically control row level security. For example, in HRMS, primary permission lists are used to control access to departments.
Row level security gives specific users access to specific data. For example, in Campus Solutions, specific users can be given access to a particular academic institution. This can also be permission list based.
PERS_SRCH_GBL is used as a search view to select person records for you to use when you access a panel. This view shows you records only for persons in departments that your operator class is allowed to access. All PER_ORG Types are returned.
PERS_SRCH_EMP is an Employment Search record containing all of the localized alternate search keys. None of the localized search keys are maked as alternate searches. However, it's easy for a customer to mark any/all of them as alternate search keys if they choose to.
Selects PER_ORG = 'EMP'
PERS_SRCH_CURR is used as a search view to select personnel for you to use when you access a panel. This view shows you records only for people in departments that your operator class is allowed to access.
Similiar to PERS_SRCH_GBL - but it does not bring back Future JOB rows.
EMPLMT_SRCH_GBL is an Employment Search record containing all of the localized alternate search keys. None of the localized search keys are maked as alternate searches. However, it's easy for a customer to mark any/all of them as alternate search keys if they choose to.
Use it to select employee records for you to use when you access a panel. This view shows you records only for employees in departments that your operator class is allowed to access.
Use this view to access records with primary keys of EMPLID and EMPL_RCD#. To access records keyed by EMPLID without EMPL_RCD#, use one of ther Personal Searches.
POI_SEC_SRCH is used as a search view to select person records for you to use when you access a panel. This view includes only People without Jobs.
One row per EMPLID and distinct Search Items.
Uses Security Sets PPLPOI
JOB_CURR_VW is a view of some of the fields of the curent Job record. It also changed EFFDT to ACTION_DT.
Only Active Employees are selected - HR_STATUS = 'A'
- PeopleTools Security
- PeopleTools Security
- PeopleTools Security
- PeopleTools Tips
- PeopleTools Tables
- PeopleTools Tables
- PeopleTools Catalog Tables
- PeopleTools Cache Clearing Guide
- PeopleTools Tip: PeopleCode Dump
- Generic prompting PeopleTools 8.50
- Generic prompting PeopleTools 8.50
- PeopleTools Reference: Common Meta-SQL
- Security
- security
- Security
- Security
- security
- Security
- 有关如何判断平面上两直线是否平行的问题
- 两个HIST怎么公用通一个X轴
- 重编译
- [转]SEO新手必须了解的六个常用步骤
- Linux后台运行MATLAB命令
- PeopleTools Security
- Matlab中的并交子集运算
- ORACLE函数大全(整理转帖)
- android多点触摸(multi touch)---待续
- linux下视频采集服务器(UDP传输、多线程模式)
- matlab随机抽样
- ORA-01536: 超出表空间 'XX' 的空间限额 (转载)
- 在tomcat上运行php
- SQL Server 函数大全(整理转帖)