Tuesday 29 May 2012

Row Level Security

Restricting Data to the Persons who are not authorized to see and also providing access to the data who are authorized to see data is called Data Security.
Row Level Security Prevents the user from being able to access data they are not allowed via the search page.

Security Installation Settings :
Set Up HRMS, Security, Core Row Level Security, Security Installation Settings
Settings are Include Home/Host, Include Additional Assignments, Job Actions that Trigger Future Dated Security Rows.

Security Sets:
Set Up HRMS, Security, Core Row Level Security, Security Sets
Defining what data to be Secured
    Security Set Table :
Transaction Sec. Join Table : Transaction Tables like SJT_PERSON, SJT_DEPT..etc
SJT Temp Table : Temporary table that is used during the SCRTY_SJTUPD Application Engine process that refreshes the transaction security join table. This table must be a copy of the Transaction Sec Join Table along with the PROCESS_INSTANCE field.
SQLID for Value Field List : SQLID of the SQL object that contains a list of the fieldnames found in the transaction security join record. This SQL is used in the App Engine Process SCRTY_SJTUPD when the transaction security join record is refreshed.
Security Access Types for this Set : This is a read-only grid that displays all of the security types that have been created for this security set and indicates which ones have been enabled

   Security Update Groups:
Groupings of data can be selected for refresh on the Refresh Trans.This allows the process to be run for just a subset of data in the SJT instead of having to refresh the entire table.


Security Type :
Set Up HRMS, Security, Core Row Level Security, Security Types
Defining How the data is secured
  Security Type Table :
Enabled :  Enable or Disable of the Security Type
Include Future Dates : Future Dated Actions can be viewed by the persons for the actions specified on the Security Installation component (Not only job, other records having future dated can be handled)
Use Department Security Tree : Check box indicates that the security access type is based on a department security tree
Transaction Table : Transaction record that contains the attribute that this security type is based on. In this case, it is the Department ID in the JOB record.
Security Keys : Provide the keys based on that data secured.Security Key1, Security Key2, Security Key3, Prompt Rec for Sec Key1,Prompt Rec for Sec Key2 and Prompt Rec for Sec Key3.
If the field is a translate value then a view must be created to return those translate values.

Special Job Security Versions : System only displays this group box when the transaction record is JOB. The fields shown will depend on which of these have been enabled on the Security Installation Settings component

   Security Type SQL:
SQLID's for the SQL objects used in the Application Engine program SCRTY_SJTUPD for refreshing the transaction SJT.

Security by Department :
1)Create the Department Security Tree
2)Create permission list
PeopleTools, Security, Permissions & Roles, and Permission Lists
3)Assign Departments to the Permission List
Set Up HRMS: Security: Core Row Level Security: Security by Dept Tree

4)Refresh the SJT_CLASS_ALL process
Set Up HRMS: Security: Core Row Level Security: Refresh SJT_CLASS_ALL

5)Assign the row security permission list on the User Profile General Page
PeopleTools, Security, User Pofiles, User Pofiles, General


Security by Permission List:

Use the Security by Permission List component for all security types that are not based on a department security tree.

1) Create Permission List
PeopleTools, Security, Permissions & Roles, and Permission Lists
2) Set up Security Set, Security Access Type and Keys
Set Up HRMS, Security, Coe Row Level Security, Security by Permission List
3) Group the Permission Lists into One Role
PeopleTools, Security, Permissions & Roles, Roles
4) Assign Roles to the Users using User Profile, Roles Page
5) Refresh SJT_CLASS_ALL, SJT_OPR_CLS and Refresh SJT Trans Process.

Nightly SJT Refresh Process to handle the future dated transactions. i.e when future dated transactions become active, it will delete the previous current data.

 Security Data Inquiry
Set Up HRMS, Security Core Row Level Security, Security Data Inquiry
This component is very useful for testing the Row Level Security after implementing and also very helpful in debugging issues.





7 comments:

  1. Gud explanation. .one more excellent blog on security search records
    http://peoplesoftconcept.blogspot.in/2014/03/row-level-security-views-as-search.html?m=1

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete
  3. Nice effort, very informative, this will help me to complete my task. Thanks for sharing it...............................Please contact us for Oracle Fusion HCM Training details in our Erptree Training Institute

    ReplyDelete
  4. This article is well written and quite informative.
    More articles should be written and you have just found a follower.and more visit.
    mainframe training in hyderabad

    ReplyDelete
  5. I feel really happy to have seen your webpage and look forward to so many more entertaining times reading here .Same as your blog i found another one Oracle Fusion HCM . Actually I was looking for the same information on internet for Oracle Fusion HCM and came across your blog. I am impressed by the information that you have on this blog. Thanks once more for all the details.

    ReplyDelete
  6. Thank you for sharing your blog, seems to be useful information can’t wait to dig deep!

    ReplyDelete