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.

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: PeopleCode, Security

We've been spending quite a bit time lately working on our Grey Sparling PeopleSoft Solution Extenders. As you can tell from reading the weblog and our main website, reporting and analytics are a key area of focus for us.

One of the interesting challenges in this area is notifying users of what they're interested in. As part of the Grey Sparling Report Security and Distribution PSE, we have built a way of delivering highly formatted custom emails to each user as well as a new Report Explorer, which greatly expands on the capabilities of the PeopleSoft Report Manager. (Don't worry - there's more meat to this post than just telling you about stuff that you can buy from us :-)

As a follow on to that work, I wanted to write up a blog post about tying in instant messaging to the report notification. PeopleSoft added some support for instant messaging back in 2003 (I actually got sucked into doing interviews when we added support for AIM and the marketing folks were out on some offsite meeting :-), but it only handled presence detection and providing "click-to-chat" links on a page.

The example here shows deeper integration. A user runs a report (or it is run for them).







When the report is done, we start a chat with any of the users that are authorized for that report (if they're online) and send them a direct link to the report.





Now the user is directly in the PeopleSoft Report Manager. Or if they are a Grey Sparling customer, they get a much nicer interface with our Report Explorer.





In order to do the deeper integration, we're actually leveraging the Smack library from Jive Software. This is an open source Java library that understands the XMPP protocol that we'll call from within PeopleCode.

For those that aren't familiar with XMPP, it is an open standard for IM (messaging and presence). Aside from Jive (who have commercial IM servers based on XMPP) and some other open source XMPP based IM servers, there are a few other big names that support XMPP. From the title, you probably already guessed that GoogleTalk, Google's IM service, is based on XMPP.

You might not know that Oracle's Collaboration Suite IM product is also based on XMPP. I don't know why they don't do a better job of marketing that - with all of the news about Google getting into IM and being standards-based, you'd think that the Oracle marketing folks would have been talking up the fact that they have a corporate solution that works with the same standard. But, I digress :-)

At a high level what we're doing is adding some new subscription PeopleCode to the message that gets sent when reports are published. The PeopleCode picks out the URL for the published report and who the report is being distributed to, and then looks to see if any of those users are online. If so, it starts a chat with them and provides the direct link to the reports.

Before I explain how you can try this out yourself, I want to point out several things about this that make it just a proof of concept and not production ready, so if you find this interesting, please don't just stick this as is into your production PeopleSoft environment!

• It connects to the Google server each time a report is published. This is OK for a little experimenting because it simplifies the code a bit, but definitely not the way to do things for real. Especially since we have to wait a few seconds to receive the presence packets from the server.
  
• The username and password to connect with are hard-coded in the PeopleCode. A production version would store this info in the DB somewhere for easier maintenance.
  
• The text that it sends out is hard-coded to one language. Works for a demo, but not the right way to do things.
  
• The error checking is less than robust. Any problems and we punt.
  
• The demo code does not listen for the user to type anything back. It's not really instant messaging if it's a one way conversation! If you look at the Smack APIs, you'll see that they support receiving text back from the user, so beefing up this code to support that wouldn't be too hard.
  
• The PeopleCode is attached directly to the PSRF_REPORT_CREATE message. We never touch delivered PeopleSoft objects in our Grey Sparling PeopleSoft Solution Extenders because we don't want to cause any upgrade or support issues, so we'd implement this differently if it became shipping product. The other day, a little birdie told me that PeopleTools 8.48 (shipping mid-year 2006) supports having subscription PeopleCode detached from the message definition itself though. Then this particular problem goes away.
• It's not multi-threaded. If you have a single report that is being distributed to a group of people, then this code sends them messages one at a time. Not very scalable.
  
• Only tested on PeopleTools 8.4x.
  

I'm sure that there's other areas for improvement here - feel free to ping us if you come up with some.

To try this yourself, you need to:

1. Have an account on an XMPP based server (such as GoogleTalk).
   
2. Download the Smack libraries and place the smack.jar and smackx.jar in your PSHOME\class directory.
   
3. Open up the PSRF_REPORT_CREATE message in Application Designer and insert a new subscription PeopleCode program (right click on Subscriptions to insert a new one). I called mine GoogleTalkNotify, but you can use whatever you want.
   
4. Add this PeopleCode, editing it for your username and password.
   

Here's what the code itself looks like. Remember that this is just proof of concept stuff and not supported in any way. You are free to use this however you want.

Labels: PeopleSoft