Security Architecture for the Peoplesoft Interaction Hub

The PeopleSoft Interaction Hub, cannot be useful without a comprehensive security strategy.  This strategy first and foremost requires you understand your organization, and the capabilities of the system.  Secondly you will need to ensure you have  done the groundwork for laying a technical foundation of Integration Broker Node Configuration and Single Sign-On.  These will need to be done before you accomplish some of the more technical challenges such as moving messages between the PUB/SUB servers.

In the red paper: Setting up PeopleSoft Interaction Hub with PeopleSoft Applications we are introduced to various methodologies to ensure User Profiles and Roles are synced between systems.  This article has good pointers in terms of technical considerations, but it falls short in some of the design details we came across.  In this blog post we will cover:

• Technologies you can use to synchronize Roles and User Profiles
• Design architectures we considered  (what worked and what didn't)
• The implementation after all things considered.

The Technology

Within the Interaction Hub, a number of delivered roles exist to grant users certain portal specific privileges some of the more common ones are: 

• PeopleSoft Administrator ~ keys to the Castle (aka the VP1 account)
• Portal Administrator ~ administer news / portal registry (structure and content) and other portal features
• Security Administrator ~ administer user profiles / roles and permission lists
• Integrations Administrator ~ administer Integration Broker related configuration

A better source for the assignment of roles lies in the Remote Content Providers, such as your PeopleSoft Human Resources system.  The HCM system should already know which users are Managers, and which users collect a pay slip.  The IH system can use these roles from the HCM system to make new Tabs or Navigation Collections for these two types of users.  So the question becomes how do move the roles from HCM to IH?

Initial Import

Perhaps the easiest way to do this would be to create all the accounts on IH that exist on all of your other servers, manually create the same roles and assign them.  This would be pretty simple to do, but would require a lot of manual work.  Working hard isn't necessarily working smart, and this process can be automated via scripts.

Before getting into scripting, it would be good to understand what you are copying.  PeopleSoft security is composed of a number of tables:

For the User Profile tables:

Attributes such as username, password, and roles are stored in the PSOPRDEFN and PSROLEUSER tables.  

Lesser known functionality is workflow notification and delegation, may not be as important, but should always be considered going forward.

For the Role tables:

Attributes such as role name, permission lists are here.   Additionally, Query Names can be stored here too.

For both Roles and User Profiles, it is important to note some of these tables, as we will be writing queries against these in the future.  

You can script the import of the User Profile tables by running USEREXPORT.DMS and USERIMPORT.DMS.  This would be done along side with adding all the Roles in HCM into a Project and Importing the Project into IH.   

After these two steps are run, we really could leave it here, but there would be a lot of work for the Security team. New accounts would need to be created in two systems, as well as any role assignments will tediously need to be manually synchronized.

Maintaining Security Through Service Operations


PeopleSoft Integration Broker uses Service Operations to move messages from a Publishing Server to a Subscribing Server.  There are 3 Service operations we have used to move roles and role assignments between PeopleSoft Servers.

Via Main Menu > People Tools > Integration Broker > Integration Setup > Service Operations you can find the following:

• USER_PROFILE ~ associated with the User Profile Tables (see above).  This service operation is triggered after particular events, such as when User Profile information is saved.  It can be useful for the following things:
• Create an account on the publishing (PUB) server, it will create it on the subscribing (SUB) server
• Adding / deleting role assignments to one account on the PUB server, will reflect the changes on a SUB server.
• Locking accounts on the PUB server will lock them on the SUB server.
• Changing attributes on Main Menu > My System Profile will publish to a subscribing server: interestingly these are also on User Profile settings.  FYI We ran into some trouble with this feature, as certain servers may need different settings: for example Email Notification and Delegation settings could not be different between our Financials and Human Capital Management Servers.
• ROLESYNCHEXT_MSG ~ associated with Dynamic Role Assignment (uses temp tables, but related to PSROLEUSER table above).  As delivered, I don't believe this process is triggered, but needs to be added as a process via Main Menu > PeopleTools > Security > Permissions & Roles > Roles > [Search for a role] > Dynamic Members on the PUB server. Dynamic Role assignment is useful as long as both Roles exist on both Servers, it will sync both servers every time, no need to do any initial syncing.
• ROLE_MAINT ~ associated with Roles, see Roles Tables (see above).  Syncing from a PUB server to a SUB server is triggered for the following:
• Create a New Role on the Pub server, broadcast to the SUB server
• Modify a role's permission list on the PUB server, broadcast to the SUB server
• Modify a role's Dynamic Queries will also be broadcast: FYI we ran into some trouble with this feature, as the dynamic query should only exist on the PUB servers.  If you point to a dynamic query that doesn't exist this will prevent the batch process from completing, and assigning dynamic queries to other systems.

What we Considered

It is important to realize the magnitude of any large change to an existing system requires rigorous discussion, design, planning and testing.

As we evolved, we went through a few configurations of this instance.  Here is our current configuration and where we would like to be:

Current Setup

Pros

• PUB Servers NOT touched, ie no implications to remote content providers.  
• No need to update service operation messages so that certain attributes will not get over written
• This method DOES work... via dynamic roles and user profiles.  Dynamic Roles don't over-write each other, as long as each role name is unique.

Cons

• No Role sync (ROLE_MAINT), the security team has to manually create roles in each environment.
• The Interaction Hub (PSFT_PA) has all the roles assignments, but the other remote content providers do not.
• Creating and modifying accounts across all servers is tedious work for the security team.

Alternative Setup

Pros:

• One system (in our Case, HCM) is the source for all USER_PROFILE and ROLE_MAINT message publishing.
• Updating / creating a user in one place: IE locking their account can be done in one place, and the message will be broadcast to all other servers.  Adding accounts is accommodated via the careers portion of HCM
• Updating / creating a role in one place will broadcast to all other servers
• Dynamic Roles still originate from remote content providers (based on query) and are assigned to the IH server to be used to drive key content.

Cons:

• This method is more complex and has a larger impact to servers other than the Interaction Hub.  We ran into the issues with the USER_PROFILE and ROLE_MAINT service operation messages copying content that wasn't relevant for each system.  See the two RED FYI's above.

Other Considerations:

Role syncing works because we are only copying role assignments between the servers.  We are not copying the permission lists.  Thus the role PSCUST_VIEW_PAYCHECK can exist on all of your PeopleSoft Environments.  The HCM Environment would have permission lists in the role that assigns access to the view Pay Slip page, but all the other environments would just have the role assignments. Again this is useful for the PeopleSoft Interaction Hub to make short cuts based on this role information, and if utilized correctly, can be a good comprehensive security strategy for your entire PeopleSoft environment.

• Roles with different functionality must not share the same names between environments. Role assignments will not be correct if a role with the same name has a different purpose.
• Accounts need to all have same psoprdefn passwords. This is key for some of your delivered accounts, that could have a certain password hard coded for example: PTWEBSERVER 

Implementation

The steps below describe how we enabled service operation security to sync user profiles and roles.

Syncing Roles / User Profiles / and Dynamic Role Assignments between systems.
-Ensure your Default Local Nodes are correctly set up
-Ensure your PUB/SUB servers are running
-Ensure you have read the steps for the USEREXPORT/USERIMPORT.dms scripts to get environments initially synced.

-Maintaining role synchronization;

• For each server in your environment, GoTo: Peopletools - IB - Integration Setup - Service Operations, search for USER_PROFILE
• Click View Message
• Disable the following table records from syncing: 

• PSOPRDEFN
• EMAILID
• DEFAULTNAVHP 
• PRCSPRFLCLS 
• OPRCLASS 
• ROWSECCLASS 

• PSROLEXLATOPRVW (this fixes the first RED FYI above)
• WORKLIST_USER_SW
• EMAIL_USER_SW
• FORMS_USER_SW
• EMPLID
• ROLEUSER_ALT
• ROLEUSER_SUPR
• EFFDT_FROM
• EFFDT_TO

Save

Do the same steps for: ROLE_MAINT Service Operation:

• PSROLEDEFN  (this fixes the second RED FYI above)
• QRYNAME
• QRYNAME_SEC
• ROLE_PCODE_RULE_ON
• ROLE_QUERY_RULE_ON
• LDAP_RULE_ON

Save

Setup Service Operation
For each of the 3 service operations: {ROLE_MAINT, ROLESYNCHEXT_MSG, USER_PROFILE}:

For PUB Servers:
GoTo: Main Menu  - PeopleTools - Integration Broker - Integration Setup - Service Operations
Search For Service Operation: {ROLE_MAINT, ROLESYNCHEXT_MSG, USER_PROFILE}

Under General

• Ensure Default Service Operation Version is Active
• Ensure Service Operation Security has been set ~ this is important for the ROLESYNCEXT_MSG service operation as it needs to be triggered by a batch process.

Under Routings

• Add a new routing
• Under Routing Definitions
• Set a name and Description
• Set Sender Node as Default Local PUB node (ie for USER_PROFILE set  PSFT_HR), and Receiver Nodes as Default Local SUB Nodes (ie for USER_PROFILE set PSFT_PA and PSFT_EP and PSFT_LS and PSFT_PF)

Return and Ensure all other routings are inactive

For SUB Servers:
GoTo Main Menu - PeopleTools - Integration Broker - Integration Setup - Service Operations

Search For Service Operation: {ROLE_MAINT, ROLESYNCHEXT_MSG, USER_PROFILE}

Under General

• Ensure Default Service Operation Version is Active
• Ensure Service Operation Security has been set  ~  this is important for the ROLESYNCEXT_MSG service operation as it needs to be triggered by a batch process.
• Ensure Generate Any to Local has been checked

Under Routings

• Ensure all other routings are inactive (except the PUB routings you created).

Set Security Override ~ when the USER_PROFILE process is triggered by a regular user saving their my system profile (this sometimes happens and blocks further messages from processing):

• Sign on into the sending system's PIA
• Navigate PeopleTools > Integration Broker > Configuration > Service Configuration
• Switch to Exclude PSFT Auth Token tab
• In the Operation field enter USER_PROFILE and ROLE_MAINT
• Click the Search button
• In the search results, notice checkbox of the leftmost column of the USER_PROFILE and ROLE_MAINT row.
• If the setup is not done, it would be UNchecked, if so click it to check and once it is checked, save the changes.