We wrote awhile back about a customization that can be done to limit a user’s roles dynamically at a signon time
, but wanted to point out an issue with it that came up recently during some customer discussions on our ERP Firewall for PeopleSoft product.
The essence of the customization revolved around creating extra tables for storing the “real” list of roles for a user separately so that the PeopleTools tables that stores the roles for a user can be modified at signon time. The way that PeopleTools is delivered there is one table that is both the “master” list of roles for a user and the “current” list of roles for the user’s session.
A little bird told me that this may get addressed in future PeopleTools versions (let’s hope for PeopleTools 8.50!), but for now the modification that we outlined in the previous blog entry is the only way to accomplish this.
So what’s the problem?
Now consider the scenario where your CFO logs in from a public kiosk at a conference somewhere to enter her expense report. You have implemented the customization to limit her roles to just those that would allow her to enter expenses and not be able to do things like pull up your P&L reports when she logs in this way.
What happens when some other process runs (batch, workflow, etc.) and checks to see who is in the high level finance roles? It won’t find your CFO. Not good.
And the answer?
One answer is to do a thorough search of all of the application code for role queries, references to PSROLEUSER, use of the IsUserInRole() PeopleCode function and modify those to use the customized “role master” table that the previous blog entry outlined.
Another answer is to wait for PeopleTools to support the notion of “session level” roles.
Another solution is to use some sort application level firewalling solution. Of course, we’re partial to our own application firewall for PeopleSoft, but there are other ways of achieving this as well.