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
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
Great article to overview the new security roles in 8.57. Thanks.
ReplyDeleteAwesome!!Good Article on PT 8.57
ReplyDeleteHi Sasank, always great to bump in one of your articles when you are try to solve a problem :) Many thanks!
ReplyDeleteStefan - Glad it was useful. Good to hear from you! :)
DeleteThanks much for the detailed post. Saved some time for me.
ReplyDeleteIn our financials system, I turned on the role alias option and waited till our app server recycled in the morning before I've assigned Portal Administrator in the Role Alias tab to a custom role. However, it does not appear to work. Any thoughts. I'm wondering if I need to wait for another recycle.
ReplyDeleteThe 'Role Alias' functionality is a way to workaround hardcoding of roles in PeopleCode.
DeleteIt does not provide permissions. That would need to be taken care of separately in the custom role.
Hi Sasank,
ReplyDeleteWe were able to create the Custom Headers. I noticed that when we uploaded SVG images using the Rich Text Editor (RTE) that is provided in the 'CompanyInfo' element's Additional Options page, it saves to the cache. If the cache is cleared, the image will then go away. If we refresh the environment from Production, the image won't exist. Is there a way to use a Logo that we have already uploaded. We have logos uploaded to PeopleTools > Portal > Branding > Branding Objects.
Thanks
Hi - Caching is problematic in the CompanyInfo functionality.
DeleteEarlier I wrote a blog series on the CompanyInfo topic.
https://pe0ples0ft.blogspot.com/2018/10/pt857-custom-header-CompanyInfo-4.html
This has a reference to all the posts. In part 2, I wrote about some of the caching issues I encountered and how I worked around some of them.
I know this does not directly answer your questions but I hope it gives you some ideas.
Hi Sasank,
ReplyDeleteWe don't really have a cache issue. I did review part 2 multiple times. We are on PT 8.58.08 so we don't really have a cache issue. Our logos are specific to each of our environments (DEV/TST, etc). We don't want the image in cache because we clear the cache after we refresh our databases from Prod. We don't copy cache from Prod after a refresh, we generate new pre loaded cache.
Previously, we would just update the PTNUI_ORACLE_LOGO Macro variable with an uploaded Branding image. Prod has all of the images uploaded so we just need to run a sql statement to update the PTNUI_ORACLE_LOGO to the right logo. Is there a way to use the uploaded Branding object image instead of Uploading the image which is stored in PS_PTRTDB and PS_PTBR_LTATTR_CLA?
Thanks
As I understand it, the whole RTE content is cached, so I don't know any way you can update or change that behavior.
DeleteIn the previous link that I shared, I succeeded in displaying dynamic text in the CompanyInfo but I have not tried that with images as I don't think there is an easy way to pass that information as a parameter.
I will let you know if I get any other ideas.