Portal Security Sync

ERP Associates has an excellent article explaining portal security sync. Remember that portal security is based on menu security for content references (CREFs) but folder security is set at the portal level.

To run portal security sync, you need access to every single folder and content reference in the portal. The two specially delivered roles that will give you this is:
•PeopleSoft Administrator
•Portal Administrator

Be warned however that PeopleSoft Administrator is all powerful!. So it is safer to give someone portal administrator if their job involves running portal security sync.

I've found that if you don't have a role that gives you access to the entire portal structure, the portal security sync application engine program (PORTAL_CSS) will run to no success (abend) with a message like this in the standard output (.stdout) file:

First operand of . is NULL, so cannot access member ItemByName. (180,236) PORTAL_CSS.CREFPERM.GBL.default.1900-01-01.Step01.OnExecute
 Name:CheckParentFolder PCPC:2339 Statement:40
 Called from:PORTAL_CSS.CREFPERM.GBL.default.1900-01-01.Step01.OnExecute Statement:202

 

Hiding a Folder using Security

Another approach is take away permission lists from the folder security tab in portal structure and content. This seems to work fine until someone comes along and runs portal security sync.

The correct way to show or hide folders is by editing menu and component security in a permission list then running portal security sync to adjust folder security accordingly. Doing it this ways ensures that the one and only reason why a user can see something is because they have access to a permission list (through a particular role) that allows them to.

Note that you should not be modifying delivered permission lists. Always clone existing permission lists and modify cloned versions. This ensures that next time you patch your security will not be overwritten!

One common issue with this approach is caching. The portal navigation menu is cached and security changes aren't always reflected immediately. You'll typically find that the folder hangs around in the left hand navigation menu even though you've taken away security (and clicking on a content reference gives the you are not authorized message).

You can tell if you have a caching problem by querying the PSPRSMPERM table to see if your permission list still has access to the relevant folder (e.g. PT_PEOPLETOOLS for the PeopleTools folder). If it doesn't then its a caching issue.

To get around this, use the purge web server memory cache servlet command by issuing the following URL for your environment:

http://[server]/psp/[site]/?cmd=purge&pwd=[password]

So at the signon screen, replace ?cmd=login at the end of the URL with ?cmd=purge&pwd=dayoff. Note that dayoff is the default PeopleSoft web profile password.

If the default password doesn't work, check the password for your web profile by going to:

PeopleTools > Web Profile > Web Profile History

Press search and look at the last loaded entry for your server name (e.g. DEV, TEST). This is the web profile in use.

Then go to:
PeopleTools > Web Profile > Web Profile

Open the web profile you found and have a look at the Custom Properties tab (last) at the auditPWD property. Note if you don't have a property, add one in with:

Property Name

Validation Type

Property Value

auditPWD String dayoff

Rather than clicking through all entries to find the Public ones you could query out PSPRSMDEFN for the PORTAL_ISPUBLIC flag.

Assign PTPT1000 Permission list to your user and bounce the application server by clearing cache....