Archive for the ‘Security’ Category

VP1/PS User ID Password Change

June 12, 2008 1 comment

To change the password for VP1/PS, following steps are to be executed.

  1. Change VP1/PS Password online. Login to the appropriate PeopleSoft instance online, PeopleTools > Security > User profile open VP1/PS profile and change the password.
  2. Shutdown appserver and process scheduler server
  3. Change the password for VP1/PS in Application Server configuration using psadmin.
  4. Change the password for VP1/PS in Process Scheduler Server configuration using psadmin.
  5. Start appserver and process scheduler server
  6. Web profile Configuration – Go to PeopleTools > Web Profile – open up the related profile and update the password in the security tab.
  7. Change the VP1/PS password in Integration broker configuration file. Go to PeopleTools > Integration Broker > Gateway open the local Gateway – Click on properties link, enter user id and password and in the gateway configuration file change VP1/PS password.
Categories: Security

Query Security

March 3, 2008 2 comments
  • Query is a PeopleTool that helps you build SQL queries to retrieve information from your application tables.
  • Query takes advantage of user’s security settings, row-level security, and primary permission list.
  • For each Query user, you can specify the records they are allowed to access when building and running queries. We can achieve this by creating Query Access Groups in the Query Access Group Manager, and then you assign users to those groups with Query permissions.  

Query Access Group Trees:

  • Trees are a graphical way of presenting hierarchical information.
  • PeopleSoft Query uses query access group trees to control the access of the tables in your PeopleSoft database.
  • Define a hierarchy of PeopleSoft record definitions, based on logical or functional groupings, and then give users access to one or more nodes of the tree.
  • Users can retrieve information only from those tables whose record definitions to which they have access.
  •  Nodes: Query access group trees contain two types of Nodes: groups and records.
    • Groups are a logical representation of a set of child groups or records. It is similar to folder in Windows.
    • Records represent a PeopleSoft record definition.
  • Structure:
    • Always use the ACCESS_GROUP Tree Structure.
    • Do not use SetID or UKV/BU.
    • Do not have Details.
    • Do not use Levels.
    • No Branches.
  • Requirements:

    • The Root Node is always a group.
    • Groups must be unique in a given Tree while records definitions can be repeated.
    • Groups and records could have Child Groups and Child Records.
    • Each record needs a unique fully qualified path in the tree. You can’t add the same record under the same parent node (group or record).
  • To open an existing Query Access Group Tree, Select PeopleTools, Security, Query Access Manager.
  • Create custom Query Access Group suitable to your organization. Create functional group names and add records under the group.
  • To Add the Query Access Groups to user:
    • Open the primary Permission List for the user
    • Go to ‘Query’ Tab
    • Click on Access Group Permissions.
    • Add the tree name, select the proper Access Group, Select ‘Accessible’ button. Repeat to add more Access groups.
    • Save the permission List.

Row Level Security:

  • By default, when you give Query users access to a record definition, they have access to all the rows of data in the table built using the associated record definition.
  • With row-level security, users can have access to a table without having access to all rows on that table.
  • This type of security is typically applied to tables that hold sensitive data.
  • For example, you might want users to be able to review personal data for employees in their own department, but not for people in other departments. You would give everyone access to the PERSONAL_DATA table, but would enforce row-level security so that they could only see rows where the DEPTID matches their own.
  • PeopleSoft applications implement row-level security by using a SQL view that joins the data table with an authorization table.
  • When a user searches for data in the data table, the system performs a related record join between the view and the base table rather than searching the table directly.

Query Security Record Definitions:

  • You implement row-level security by having Query search for data using a query security record definition. The query security record definition adds a security check to the search.
  • Query security record definitions serve the same purpose as search record definitions do for panels. Just as a panel’s search record definition determines what data the user can display in the panel, the query security record definition determines what data the user can display with Query.
  • To get Query to retrieve data by joining a security record definition to the base table, you specify the appropriate Query Security Record when you create the base table’s record definition.

To apply row level security:

  1. Select PeopleTools, Application Designer to open the Application Designer, and open the record on which you want to apply row-level security.
  2. With the record definition open in the Application Designer, click the Properties button, and select the Use tab from the Record Properties dialog box.
  3. Select the security record definition (usually a view) in the Query Security Record list box.
  4. Once you’ve set the query security record definition, click OK to close the Record Properties dialog box, then save the record definition. If you’ve already used SQL Create to build a table from this record definition, you don’t need to rebuild it.
  5. Note. PeopleSoft row-level security views restrict users from seeing certain rows of data. To secure data through the search record, simply put one of the three Row Level Security fields on your record as a Key, not a List Box Item. The three Row Level Security fields are OPRID (User ID), OPRCLASS (Primary Permission List), and ROWSECCLASS (Row Security Permission List). If one of these fields is on the search record as a Key, not a List Box Item, PeopleTools does the following. PeopleTools adds a WHERE clause when it performing a SELECT through the record forcing the value to be equal to the current user’s value.

Forgot Password functionality

December 15, 2007 1 comment

Please visit Brent’s PeopleSoft corner blog for complete details.

Categories: PS Admin, Security

Signon PeopleCode modification

December 11, 2007 6 comments

We had a requirement to track unsuccessful login details. PeopleSoft delivered PSACCESSLOG table gives only successful login details. To get unsuccessful login details, I modified PASSWORD_CONTROLS() function in  FUNCLIB_PWDCNTL.PWDCNTL.FieldChangePeopleCode

To do this I created a record ACCESS_DET with OPRID, LOGGINDTTM etc fields. This record stores all unsuccessful log-ins data. Then Open the peoplecode (Record.FUNCLIB_PWDCNTL, Field.PWDCNTL, Peoplecode.FieldChange)  and added the below shown PeopleCode inside the password_controls() function, where the %PSAuthResult value is negative.

      Local Record &ACCESSREC;
      Local SQL &ACCESS_SQL;
      &ACCESSREC = CreateRecord(Record.ACCESS_DET);
      &ACCESS_SQL = CreateSQL(“%Insert(:1)”);
      &ACCESSREC.LOGINDTTM.Value = %Datetime;
      &ACCESSREC.LOGINATTEMPTS.Value = &FailedNum;

Related articles in other blogs:

Record Audit

December 7, 2007 24 comments

PeopleTools ver 8.45 

To audit an already exisiting PeopleSoft record, we need to create a record definition and SQL table in which we store audit information. When creating the audit record, remove any attributes such as
PARENT records, Query Security Records, and PeopleCode. The easiest way to create an audit table is to open the record definition of the base record that you wish to audit. Save it as a new record, prefaced with AUDIT_.

Remove the all edit and key attributes from the newly saved record. Also remove any attributes such as
PARENT records, Query Security Records, and PeopleCode. Add to the top of the audit record the following three special audit-specific fields in the same order given below.


In most cases you should include AUDIT_OPRID, AUDIT_STAMP, AUDIT_ACTN. The AUDIT_STAMP must be given the attribute AUTOUPDATE. You might also add AUDIT_RECNAME if you are creating an audit table to audit more than one record definition.

Make these fields required and keys. Then build the table. Make sure you can query this table using sql editor.

The purpose of each audit specific field is explained below.

AUDIT_OPRID – Identifies the user who caused the system to trigger the audits—either by performing an add, change, or delete to an audited field.
AUDIT_STAMP – Identifies the date and time the audit was triggered.
AUDIT_ACTN  – Indicates the type of action that the system audited. Possible actions include:

  • A: Row inserted.
  • D: Row deleted.
  • C: Row changed (updated), but no key fields changed. The system writes old values to the audit table.
  • K: Row changed (updated), and at least one key field changed. The system writes old values to the audit table.
  • N: Row changed (updated), and at least one key field changed. The system writes new values to the audit table.

AUDIT_RECNAME –  Identifies the name of the record definition that was audited.

The audit table does not have to include all the columns of the base table. In fact, for performance reasons, it’s best to only include those fields in your audit record that are deemed

Open the record properties for the record you want to audit, Under the Record Audit, we have the following options

Record Name – Specify the user-defined audit record.

Audit Options – following are the audit options to choose for auditing the record.

  • Add –  Inserts an audit table row whenever a new row is added to the table underlying this record definition.
  • Change –  Inserts one or two audit table rows whenever a row is changed on the table underlying this record definition.
  • Selective –  Inserts one or two audit table rows whenever a field that is also included in the record definition for the audit table is changed.
  • Delete –  Inserts an audit table row whenever a row is deleted from the table underlying this record definition.

Now perform online transactions on the audited table, query the audit table to know what is changed and who changed it at what time.

Categories: PT, Security Tags: