PeopleSoft Fine Grained Auditing – Part II

Now, letlet’s test this policy. Log on to PeopleSoft environment using the browser and create a PRIVATE query referring to the above table. The query will not have any criteria and will fetch all rows (this table only had 1002 rows).
After executing the query, the audit data is populated in DBA_FGA_AUDIT_TRAIL.

select timestamp, db_user, client_id, object_name from dba_fga_audit_trail where object_name = ‘PS_ABC_COMPANY_TBL’

/

TIMESTAMP DB_USER CLIENT_I OBJECT_NAME

——— ——– ——– ———————

21-MAY-07 SYSADM NPAI PS_ABC_COMPANY_TBL

21-MAY-07 SYSADM NPAI PS_ABC_COMPANY_TBL

We can also, select the actual TEXT executed by the user by selecting the SQL_TEXT column in the above data dictionary view.

Summary:

I have shown a small example utilizing FGA for auditing the PeopleSoft database. FGA is a neat feature and allows us to audit specific rowset instead of auditing all the rows in the table. This is very useful when there exists a table which has sensitive + non-sensitive information, and you want to audit any un-authorized access to the sensitive column or rowset.

Note 1:

* As of 9i, FGA feature only allows auditing SELECT. 10g supports SELECT, DELETE, UPDATE and INSERT statements.

Note 2:

If you need to drop the policy then use the below SQL

begin

dbms_fga.drop_policy (

object_schema=>’SYSADM’,

object_name=>’PS_ABC_COMPANY_TBL’,

policy_name=>’ABC_COMPANY_TBL_ACCESS’

);

end;

Bug Note:

Do not forget to check out the bug related to FGA

http://www.red-database-security.com/advisory/oracle-fine-grained-auditing-issue.html

Read More About  PeopleSoft Fine Grained Auditing

Take 3: Jolt Session Pooling Covered….

Before reading this entry (always a friendly warning first!), please read about my two blog entries that I posted earlier. This entry is kind of closure to my previous topic “Jolt Session Pooling”. If you still have decided to read this one, you cant complain about not able to understand this one….

In our last blog entry, we talked about Jolt Session Pooling. As I stated earlier, Jolt Session Pooling is enabled by default in Tools Version 8.48 and later. Considering this new feature(!), there are some things that are changed due to this parameter single change starting with Tools 8.48 and later….

Also, we talked about the sevlets (like psc, psp etc) that are having ‘definitions” in the web.xml file (under DOMAIN/PORTAL/WEB-INF directory). So, back to our main point.. why JoltPooling needs to be disabled for all the servlet entries in the web.xml file to resolve the “download to excel” button to work… Probably you have guessed it already.

The key point here is, when Jolt Session Pooling is enabled, the session is shared across all the servlets. The existing sessions are shared across multiple servlets within weblogic server. This is supposed to be provide good performance results. There are no dedicated sessions. As of now, I know some of the effects of this change in 8.48 environment:

1. “Download to Excel” button not working
2. Tuxedo is unable to list the online users on the system
3. “View Attachment” is not working
4.  

If you know anything else due to this “Jolt Session Pooling” enabled option causing in Peoplesoft, please write on the comment below for me to know and learn. My policy is to share the knowledge and feel free to learn. 

To know more about Jolt and Weblogic, I would recommend you to read the BEA documentation about “Using BEA Jolt with BEA Weblogic Server” Guide. I am going to write some new things going forward… One of the m is about my favorite. Inter Process Communication in the Unix System and Peoplesoft.

Read More About  Jolt Session Pooling

Fine Grained Access Control for PeopleSoft Database – II

previous post…

 Here are the steps to implement the Fine Grained Access Control feature to mimic the row-level security in your PeopleSoft online Query Manager.

Step 1:

We will create a function QRY_SEC_FUNCTION that will be used by the policy to add the filter.

create or replace function QRY_SEC_FUNCTION (schema_name IN varchar2,

table_name IN VARCHAR2)

return varchar2

as

V_OPRID VARCHAR2(32);

V_emplid varchar2(20);

V_CLIENT_INFO VARCHAR2(1000);

V_QRYSECRECNAME VARCHAR2(32);

V_SQL_TEXT VARCHAR2(4000);

V_TABLE_NAME VARCHAR2(32);

begin

V_CLIENT_INFO := SYS_CONTEXT(‘USERENV’,'CLIENT_INFO’);

V_OPRID := SUBSTR(V_CLIENT_INFO,1,INSTR(V_CLIENT_INFO,’,',1)-1);

V_TABLE_NAME := TABLE_NAME;

If V_OPRID is null then

V_SQL_TEXT := ‘EXISTS (SELECT ”X” FROM PS_PERS_SRCH_QRY A1 WHERE A1.EMPLID = ‘||V_TABLE_NAME||’.EMPLID AND A1.OPRID = USER)’;

else

V_SQL_TEXT := ‘1=1′;

end if;

RETURN V_SQL_TEXT;

exception

when others then

return ‘1=1′;

end;

/

Step 2:
Now, we will create the policy

begin

dbms_rls.add_policy

( object_name => ‘PS_PERSONAL_DATA’,

policy_name => ‘PERSONAL_DATA_POLICY’,

policy_function => ‘QRY_SEC_FUNCTION’,

statement_types => ’select’,

update_check => TRUE );

end;

That’s it!!
Now let’s test the result…

As we can see above, now our results from the database match the results from online query. The function has dynamically added the additional criteria similar to what was done by Query Manager.

Summary:
In today’s world, it has become critical to ensure that there are no security loopholes in the system that will expose data to people who should not be seeing them. Row-level security provided by PeopleSoft helps us secure online access and we most often forget that users setup in the database can by-pass this security and have access to all the data. FGAC helps us replicate the online row level security in the database thus helping us further secure the database.

Read More About  Fine Grained Access Control

How to create new Manager Self Service Transaction?

As everyone knows, PeopleSoft itself provides a lot of MSS transaction.

For example

1. Transfer Employee
2. Job Change
3. Promote Employee
4. Terminate Employee
5.  

Like that, say for example, if we are getting new MSS related requirements for Paygroup Change, How will we accomplish? Here is an insight!!!

Broadly saying, we should have 3 types of components that needs to be built to accomplish any MSS transaction

1. Transaction Level Components
2. Approval related Components (If Required)
3. Viewing Transaction/Approval Workflow Status related Components
4.  

Each of these components are in turn driven by 2 types of Component Pages, one for Launching Manager’s Direct Reports and the other one for Adding / Approving/ Viewing a (Paygroup change) Transaction.

In order to maintain all these transactional and approval workflow status related data, we should create 2 records to hold the data. As per PS Convention, One of the ways to maintain the data is achieved by having

1. HR_PAYGRPCHG_DAT – This record used to hold all the (Paygroup change related) Transactional data
2. HR_PAYGRPCHG_STA – This record used to hold all the Approval Workflow Status related data
3.  

Transactional Level Components

This type of components is purely meant for doing transactional changes. In our case, transactional change is nothing but Paygroup change for an employee.

1. Launching Page:
2. 
   Manager’s Direct Reports  Launching Component Page is constructed either by Direct Report Setup (Using OPRROWS component to show Direct Reports) or Configure Direct Reports UI Setup (Using HR_DR_SELECTION_UI component to show Direct Reports)
   Navigation: Setup HRMS >> Common Definition >> Direct Reports for Managers
3.  
4. Transaction Page:
5. 
   Transactional Component Page should be manually built as per the Requirements. As a manager, this is where Manager has to change the Paygroup of an employee, which in turn will fire Approval workflows (if required) or insert the data to Job component directly.
   Once the data is saved on this page, it should insert this transaction related data to DAT record and all the Approval workflow related data to STA record.
6.  

Approval related Components / Viewing Approval Workflow Status related Components

1. Launching Page:
2. 
   The Launching Page for both Approval / Viewing Status related Components should be manually designed to populate the Manager’s Direct Reports.
3. 
   Basically Launching pages are used to show the Direct Reports of the Manager. But in this case, Population of Manager’s Direct reports is restricted. For Eg. If the MSS transaction needs an approval, then the corresponding employee for that transaction will be shown as one of the Direct Reports in Launching page. Needless to say, Showing data for Manager’s Direct Reports should be determined by both Transactional (HR_PAYGRPCHG_DAT) and Status (HR_PAYGRPCHG_STA) data records.
4.  
5. Transaction Page:
6. 
   In the case of Approval related components, the main Approval page should be provided with 2 extra buttons to approve or deny the transaction. All other transactional data information should be placed in this page in non editable mode.
7. 
   For Viewing Statuses, the entire page should be in READ only access mode. This page should be used only to view the transaction and approval workflow status related details.

Read More About  Self Service Transaction