Friday, October 19, 2018

PeopleTools 8.57 | Branding Administration Access and New Roles

Most of you know that PeopleTools 8.57 is generally available on Oracle Cloud. I used a trial account to install a PUM image (HCM 9.2 PI 27 - PT 8.56) on Oracle Cloud Infrastructure - Classic (OCI-C) using PeopleSoft Cloud Manager 7. Once I got the HCM PUM image up and running, I upgraded it to PeopleTools 8.57.01!

The first thing I noticed while accessing some of the existing (pre-PT 8.57) Branding pages is that I was getting a new (strange) security error. Strange because I was accessing these pages as PS user.

Here are some example pages where we will run into this error:
PeopleTools > Portal > Branding > Branding Objects
PeopleTools > Portal > Branding > Define Headers and Footers


'Secure Branding Administrator' Role

This error occurs even if we already have access to the previously known "all powerful" roles such as 'Portal Administrator' and 'PeopleSoft Administrator' which should usually give us full access to Portal functionality. In PeopleTools 8.57, there is an additional/new role called 'Secure Branding Administrator' which is used to control access to certain Branding pages. This condition is hard-coded on the Component SearchInit PeopleCode as shown below in this example.


'Secure Branding Administrator' Role


Once we add this role to the required users, they should be able to view the affected Branding pages.

'Company Info Administrator' Role

Once we get past this security error, I am assuming most Branding admins would want to review the much awaited 'Company Info' feature in PT 8.57.

PeopleBook: Configuring a Custom Banner

If we follow the steps described in PeopleBooks and try to find the 'CompanyInfo' element in the DEFAULT_HEADER_FLUID header definition, it is nowhere to be seen. We can see that the element is referenced in the order property of pthdr2container as shown below. Yet we cannot see the 'CompanyInfo' which should be the second element under DEFAULT_HEADER_FLUID after ptdropdownmenu and before pthdr2container.


In PT 8.57, there is a new delivered role called 'Company Info Administrator' which is required for us to be able to view and configure the 'Company Info' element. As shown below, we can see the CompanyInfo element after adding the 'Company Info Administrator' role to the user in question.


'PeopleTools SVG Administrator' Role

Lastly, if we want the ability to upload SVG images using the Rich Text Editor (RTE) that is provided in the 'CompanyInfo' element's Additional Options page, then we must have access to a new delivered role called 'PeopleTools SVG Administrator'.

Uploading a SVG image using the Rich Text Editor without 'PeopleTools SVG Administator' Role will generate the following error.



Bug with 'PeopleTools SVG Administrator' Role

While testing the SVG image upload feature via the Rich Text Editor available on the CompanyInfo element - 'Additional Options', in some cases, I found that we could upload a SVG without any issues even if we did not have access to 'PeopleTools SVG Administrator' role.

When I dug into the code, I found this security check condition is case sensitive! 😂



This means that if we upload a SVG image with a capitalized or mixed-case extension (e.g.: CSK_LOGO_32.SVG instead of CSK_LOGO_32.svg), we can simply bypass the security check. I created a MOS SR related to this topic and the following Bug has been logged!

BUG 28818544 - E-SEC USER WITHOUT THE PEOPLETOOLS SVG ADMINISTRATOR CAN STILL ADD .SVG IMAGES

Using Role Alias Functionality instead of using Delivered Roles

For many PeopleSoft customers, it may not be an ideal practice to add/use delivered roles in a production environment. Generally speaking, most customers rightly avoid using delivered roles and rather create cloned versions of them to eliminate any impact during upgrades/patches. This is a great approach except when we constantly run into scenarios as described in this blog where delivered roles are hard-coded in PeopleCode by Oracle/PeopleSoft developers. In such circumstances, we have no choice but provision the hard-coded delivered roles. The other alternative is to customize the hard-coding and replace it with a custom role (which is also not ideal!).

Starting with PeopleTools 8.55 there is a hugely understated security feature that was introduced to address this problem. It is called the 'Role and Permission List Aliases' functionality and for what it is worth does not get the necessary air time. Using this functionality, instead of provisioning the delivered roles to end users, we can simply configure a custom role alias(es) to the delivered role which will workaround the hard-coding in PeopleCode!

More Information on this topic is available in this PeopleBook Reference:
Using Role and Permission List Aliases

1 comment:

  1. Great article to overview the new security roles in 8.57. Thanks.

    ReplyDelete