I’ve decided to work a little harder to make myUMBC work for more users. Of course, the ulterior motive is to save work for myself and the help desk. Actually, sometimes my entire job seems geared towards doing things to save myself work. I guess once I’m completely successful, I’ll be able to just sit around my office and surf porn all day long. But anyhow..

We really need a way to make myUMBC work for people without a SSN (soon to be HP-ID) attribute in LDAP. Background on this problem is here. These people are able to log into the portal, but since we can’t look up an identifier for them, we can’t authenticate them to the legacy portal code. As a result, they can’t properly render any of the web proxy channels served by the legacy portal server. These channels handle all of myUMBC’s SIS related functionality (IOW, most of what you currently would want to do in myUMBC), so in effect, this leaves these users dead in the water.

[More:]

Now, unless we know the user’s HP-ID, the user still won’t be able to do anything really useful in the portal. However, we’d still like for them to be able to navigate through the portal and see the channels. To fix the user “for real”, we need to do one of the following:

1. Manually query SIS to see if the user has an HP-ID. If so, check LDAP to see if the user has multiple entries, and merge the entries if necessary. Otherwise, manually add the user’s HP-ID to LDAP, so we can map the username to the HP-ID. If no HP-ID in SIS, instruct the user to contact the registrar’s office and request one.
2. Do nothing, and hope the problem resolves itself (might just have to wait for the user’s info to percolate through the various systems of record).

What we’d ideally like to do, is get the portal to do the work for us. If a user logs in and we can’t find an HP-ID for them, we need to get in their face and tell them to contact the registrar to correct the problem (duplicate LDAP entries are a difficult issue, though.. I’m hoping that some of our problems with them will go away after we finish with SSN remediation). But in the meantime, we should make portal navgation work for the user, so they can at least get to functionality that doesn’t require a “real” HP-ID.

The solution I came up with, was to assign the user a “fake” HP-ID on the fly when they initially log in. We can then use that as a primary key for the legacy session management table (auxil.www_sessions), and the user will be able to render the legacy web proxy channels.

The basic logic for getting a session table key now looks like this:

1. Query auxil.myumbc_user_preferences table for an SSN (HP-ID) that matches the user’s UMBC username. If successful, use that. This allows us to map the user’s LDAP SSN to the SIS SSN when the two differ, which happens a lot when the user’s SSN changes and the change hasn’t percolated to one or the other system. Hopefully, we won’t need this step after SSN remediation, because the HP-ID is never supposed to change.
2. Query LDAP for the user’s SSN (HP-ID). If successful, use that.
3. If we couldn’t find the SSN that way, query the legacy session table for a temp SSN matching the username (indicating that we’ve already created them a temp identifier). If we find one, use it.
4. If all else fails, generate the user a temp identifier within a specified range (currently 995000000-995999999) and use that.

The user is thus able to render legacy channels right away. And the nice thing here, is that once the user gets a “real” SSN (HP-ID) in our system, it’ll automatically stop using the temporary one without any intervention on our part.

All of this magic happens in edu.umbc.uportal.UmbcPersonFactory, which currently lives in the main uPortal source tree.

I have this in production now, and I’ll be keeping an eye on it to see what problems develop. If it seems to be working, we’ll need to see about somehow hassling the user to get the problem rectified. This might be something to do via the big, fancy, vaporware alerts system we’re supposedly launching this fall.

The fun never ends..