×
Security

Dynamic PeopleSoft Security Based on Login

By Larry Grey • January 19, 2006

(update : see ERP Firewall for PeopleSoft)

A few years back I had the opportunity to help out with an interesting customer requirement for dynamic security based on where the user is logging in from. Kirk Chan (another ex-PSFT person) and I got to spend quite a bit of time working with the customer on this. In the end, it was quite successful. In fact, they even presented on this at one of the PeopleSoft Connect user conferences.

The customer was rolling out PeopleSoft eBenefits to tens of thousands employees, a large number of whom didn’t have access to the corporate network except over the public internet. The challenge was that they didn’t want to take any chance that, for example, the VP of HR logs in from a kiosk machine somewhere to do his or her benefits, gets their password swiped, and then someone has access to all of the HR system. So anyone logging in over the internet was to only get the needed privileges for accessing the eBenefits pages, and nothing else. If they logged in from the internal network, then they would receive their usual access level.

Making matters more complicated was that they were about 30 days from their code freeze cut-off date for what would be rolled out. The benefits open enrollment period wasn’t something that can be changed just for dealing with code changes. If this couldn’t be implemented, then they would have to go back to doing things the old way (where most employees would fill in their info on paper). That would be pretty expensive.

Another complication was that their IT group was definitely in the “show me” mood. Later on, we were able to speculate why they didn’t have much confidence in their software vendors at that moment 🙂

So, how’d it work?

The key to this was some custom signon PeopleCode, a couple of extra tables for storing some additional data and a couple of modifications to the one of the delivered security maintenance pages. We got lucky in that they had an ex-PSFT person onsite doing some consulting who helped with the actual implementation of the code for them (Hi Maverick!). What I’m about to describe is actually simpler than what they did because of some additional requirements of theirs (users being able to opt out completely from their account being exposed over the Internet) that I won’t go into in any detail here.

(update: see this blog entry for more things to consider in looking at this customization)

What the signon PeopleCode did was to check which servers they were coming through (this is accessible in the %Request object) and then populate the PSROLEUSER table for them based on that.

The PSROLEUSER table is the table that PeopleTools uses to know what roles a user has. All of the delivered dynamic role stuff (sourcing roles via Query, or LDAP or a custom PeopleCode program) all populate this table.

This is important to understand – if there isn’t an entry in this table for a given user/role combination, then the user does NOT have that role. At runtime this is the only place that is checked for roles. The Internet Architecture does not run any queries or access LDAP servers to determine the roles, they always come from the PSROLEUSER table. You can test this out by deleting rows from this table in a demo system while you are logged in. You will lose the role(s) immediately. Unfortunately the internal PeopleTools code for handling roles that change in mid-session is really bad from a usability perspective – it’s not graceful at all).

Once we know which server the user is coming through, the signon PeopleCode would flush the existing list of roles for that user, and then re-populate it from a shadow table that was created. The shadow table was essentially a clone of PSROLEUSER, but it served to act as the “master” list of the overall set of roles that a user had. The signon PeopleCode would filter this list based on what roles were deemed appropriate for the server that the user was logging in through.

In order to keep this shadow table up to date, the delivered page for maintaining user/role combinations had to be updated to store it’s changes into the shadow table instead of PSROLEUSER. The delivered programs that source role info from Query and/or LDAP also needed small changes to write into the shadow table and not PSROLEUSER.

In a nutshell this work splits out the notion of overall roles and current roles. With the delivered PeopleSoft configuration, these two are tightly linked together. Fixing this was one of the things that was likely for PeopleTools 9.

(note: there are some other ways to do this without changing the delivered objects, but they get a little tricky and the customer didn’t care about the slight bit of extra maintenance in exchange for this functionality).

This particular problem was very focused on the notion of dynamic security based upon whether someone was logging in from inside the firewall or not, but it would be easy to extend it to other scenarios, such as the time someone was logging in. An example might be a student intern in the HR department only gets HR system access during their assigned intern hours, but they’re given access to the Student Admin pages 24/7.

Another scenario would be how the user was authenticated. If someone logs in using a SecurID token, you might grant them a higher level of access than if they only used a username and password.

There’s another scenario where this technique could be applied, but it’s probably worth it’s own blog post because there’s a couple of different ways of solving it.

Labels: ,

Stay Updated

18 Replies to “Dynamic PeopleSoft Security Based on Login”

  1. You’re right that it is complicated. There are a number of issues with trying to change roles dynamically at login time (including some that we didn’t even realize at the time that this blog post was originally written – 5 years ago). That is ultimately what led us to building a bolt-on product, the ERP Firewall for PeopleSoft, to solve this in a easy to install and implement fashion.

    One problem with dynamic roles is that they are intended to change the list of people in a role system wide. Having this run everytime that someone logs in is not going to work well. That’s part of the reason that the dynamic role setup prompts you to schedule the dynamic role updates ; it’s not intended to be run at login time.

    You’ll also hit some issues with trying to use PSACCESSLOG for querying against as part of the current login (you need to have the roles updated before the login process actually completes).

    There are other issues that we’ve run into as well in working with customers on this that some of the linked blog entries above go into in more detail.

    If you’re interested in discussing this live, just shoot us an email and we’d be happy to chat briefly about it.

  2. We have student employees that we’d like to be able to restrict usage to by time of day and to on-campus ip addresses only. Reading thru the PeopleSoft Security documentation it seemed like I ought to be able to create a custom table to record allowable work times by student employee and then make their access a dynamic role which compares the allowable times stored in the table to the current date/time as part of its assignment criteria. I would also add to the validation criteria a validation of the login ip address from PSACCESSLOG.

    What you (and others) have described here seems much more complicated. Does this mean that using dynamic roles in the manner I describe won’t work? Or was the scope of your projects more extensive/complicated?

    Thanks!
    Rona

  3. If you block URLs that contain the string “psc”, then you’re not going to be able to do much in PeopleSoft.

    What are you actually trying to do?

  4. Hi,
    I’m responding to Ken’s message about using PeopleSoft behind an ISA server. I’m currently trying to setup SSL with an ISA server and having fits. I can hit the PeopleSoft signin page but then get an “Authorization Error” message upon login. Any tips for how you configured the PIA with ISA?

    Thanks!
    – Rob

  5. There’s actually a lot of limitations to signon peoplecode.

    Not being able to redirect is one of them, but there are other things that don’t work as well. We recently had one of our customers that needed to be able to set the user’s session language code dynamically at signon time, which you think you’d be able to do in signon PeopleCode, but when you set the language code, it doesn’t “stick”.

    We ended up implementing the notion of “Session Established” peoplecode processing to be able to support things like this that should happen after login. It took a fair amount of work to make that work properly though.

  6. How do we redirect to a component based on a role from signon peoplecode instead of home page

    Giri

  7. We currently use an ISA reverse proxy server that runs against our WebLogic peoplesoft webserver. This reverse proxy server is the only route to the application from outside of the company firewall.

    Looking ahead at Tools 8.49, I have read about the RPS plug-ins available for WebLogic. There are basically 4 that have supported plug-ins (one of them being IIS).

    I am trying to understand what installing and configuring these plug-ins would enables you to do? The existing non-certified ISA to WebLogic configuration seems to fit our needs without any plug-in.

    About the only benefit I’ve found is a possible performance boost related to connection pooling. Here’s a note about that:
    http://e-docs.bea.com/wls/docs92/plugins/isapi.html

    Anyone have any advice on the benefits of the plug-in to WebLogic?

    Thanks,
    Ken

  8. You’d have to see if the old user conference presentation databases are still online within Customer Connection/Metalink.

    This was a few years back (2005 I think) so they may not be though.

  9. Chris,
    Would it be possible to share the presentation that your customer has presented on ‘Dynamic PeopleSoft Security Based on Login’.

    I am currently investigating the feasibility of implementing this feature in our environment.

  10. Hi, I’m trying to find the table that keeps the information of the last login of users to PeopleSoft. Do you know the name of the table?

    Thank you.

  11. We are using a separate reverse proxy server to prevent users from typing other portal names in the URL. This server is also being used to restrict access to only the script portions of the /psc/ area. In other words, the only area enabled within /psc/ are items that exist under /HRMS/s/ and not allow access to anything /HRMS/c/.

    The firewall tool looks like a great solution though. Compared to the complexity and cost of adding a separate reverse proxy server this product seems great. And looking at the features it seems to do more than we could do with this current RPS solution with much less overhead in maintaining it. I’ll send a separate email to experts@greysparling.com to have my email address included on any additional updates about the ERP Firewall product. Thanks for all the information.

    Regards,
    Ken

  12. Keep in mind that the EMPLOYEE portal is still completely accessible.

    In your example where someone had typed in

    http://webserver:9999/psp/
    PRODENV/CUSTOMER/
    HRMS/c/
    SomeMenuUsedInAnotherPortal.
    ComponentRegisteredInAnotherPortal

    they could have just as easily typed (or selected from a bookmark)

    http://webserver:9999/psp/
    PRODENV/EMPLOYEE/
    HRMS/c/
    SomeMenuUsedInAnotherPortal.
    ComponentRegisteredInAnotherPortal

    Another problem is that someone can just change the /psp/ to /psc/ and bypass the portal completely. The /psc/ servlet is what sends out the actual transactional content that is hosted in the frame that the portal wraps.

    We’ve actually been building out a product recently that addresses these sorts of issues. It’s in beta-testing at one of our customers right now, and has been shown to one other potential customer, but hasn’t been made generally available yet.

    This isn’t linked from our main product page yet, but here is the high level overview document for it.

    http://www.greysparling.com/brochure/GS_ERPFirewall_for_PeopleSoft_Overview.pdf

    Take a look and let us know what you think.

  13. I had the issue of trying to prevent users from displaying components from other portals by simply typing in the URL directly. So for example, someone logs into the customer portal and views a page there…

    http://webserver:9999/psp/
    PRODENV/CUSTOMER/
    HRMS/c/somemenu.
    somecomponent

    Now if they are logged in with a user id that has security to components that are registered in other portals (like EMPLOYEE), they can just type them in and this portal will also display them.

    http://webserver:9999/psp/
    PRODENV/CUSTOMER/
    HRMS/c/
    SomeMenuUsedInAnotherPortal.
    ComponentRegisteredInAnotherPortal

    Even though the user would not be able to use the left menu to navigate to that component, if they can figure out the menu and compenent name to type in, they could view it in the CUSTOMER portal.

    To prevent this, we unchecked a setting on the Security tab of the Web Profile called ‘Allow Unregistered Content’. There isn’t really a great deal of documentation about the setting in peoplebooks or on customer connection, but it seems to resolve this security gap.

    Anyone else find this setting useful or have some additional documentaion on it?

    Thanks,
    Ken

  14. Hello,
    Do You know witch PCode is executed at signon page, excepted et FUNCLIB_LDAP function ? I’d like to hook the USERID and the PSW to authenticate user within a peoplesoft page to a Microsoft Reporting Services site.
    Thanks.

  15. Cool.

    It’s definitely a pretty common thing to want to do. We had been planning to make this easier in PeopleTools 9, but….

    One thing to keep in mind with the portal providing security is that you can always build up the direct URL to the PeopleSoft content servlet and completely bypass the portal. This is as easy as changing the /psp/ portion of the URL to /psc/. You lose the nav that the portal provides, but you’re directly into the page.

    This is true in the case where the portal is serving up application pages through the framed templates (which is the default from the install). You can make the portal proxy content through it, so you can cut off direct access, but there is a pretty big performance hit. Enough of a performance hit that we couldn’t ship applications running in this proxied fashion. There were some plans for PeopleTools 9 to change the component processor logic to make it easier for the portal to proxy PIA-generated pages, but it only hit the planning phases.

    As a historical note, this is why the context manager part of the portal works the way that it does (loading in a separate frame).

    One other trick for doing additional security in these sorts of situations is to use Page Activate PeopleCode. You could test for certain conditions (server being used, etc.) and grant access to the page based on that. Not very scalable, but handy if you just want to really restrict access to a couple of key pages (I always used the Wire Transfer page in the Treasury application as an example for this).

    P.S. We get a lot of traffic from your weblog links. Thanks!

  16. Very cool…I just was working on something similar to this last month. We wanted to limit menu items based on whether someone came in through the External URL or the Internal URL for the same reasons you mentioned about a password getting swiped. What I did was create a separate Portal (SELFSERVICE) that the external URL came in through. The internal URL still went to the EMPLOYEE portal.

    One issue I had though was when inside the SELFSERVICE Portal via the external web profile, a knowledgable PeopleSoft person could just manually change the URL to go to the EMPLOYEE Portal and then you were inside everything. To fix that, I customized PT_NAV PeopleCode to not build the left hand nav based on the URL & Portal Name pairing. I couldn’t think of a cleaner way to do it unfortunately.

Comments are closed.

Request a Demo