OR…. How I Finally Got to Use Some Really Cool EIM Security Functions to Enable SSO for a SaaS Implementation
I love working on single sign-on projects that stretch the capabilities of Kerberos and EIM. Love them even more when they open up the possibility of using SSO to access popular SaaS applications, such as the Jack Henry Banking’s Outlink Processing Services.
This story starts a couple of months ago when I received a call from someone at Jack Henry & Associates, Inc. It seems their Outlink Processing Services division (the one that allows banks to outsource their IT bank processing applications and hardware) had a potential customer that was already using SSO implemented with Kerberos and EIM. The bank was reluctant to move to Jack Henry if it meant they had to give up their SSO. Go figure!
The resourceful Jack Henry salesperson had found his way to me and asked if it was possible for the bank to continue to use SSO even though the IBM i was not located within the bank`s network. After asking a couple of questions about how bank employees would connect to the Jack Henry system without SSO, I assured the salesman that it could be done. In fact, I told him, the bank itself wouldn’t have to do much different from what they do now in terms of configuration.
Jack Henry, on the other hand, would need to do some special configuration to support multiple banks using SSO to connect to a single Jack Henry partition. Obviously, Jack Henry already supported this with robust security for existing customers — sans SSO. Jack Henry needed to ensure that SSO wouldn’t compromise any of this set up.
From a security point of view, accessing a system through green screen sign-on via SSO has no effect on access control or security in general. But the data in EIM could be used to circumvent security if an attacker from one bank, for example, could change their EIM association to a user profile for another bank.
Configuring SSO for the Bank’s Employees
The three parties agreed to move forward with the project. The configuration was done online in a GoToMeeting session. We used the Network Authentication Service (i.e. Kerberos) configuration wizard in System i Navigator (iNav). They already had the Jack Henry system as one of the connections in iNav. We expanded that system, right-clicked on Network Authentication Service (i.e. Kerberos), and selected “Configure…” We did the usual Kerberos configuration stuff. Then we ran the Windows batch file on the bank’s domain controller. Finally, we did our initial Kerberos configuration testing from the Qshell on the Jack Henry IBM i system. This all worked as expected.
Next, we ran the Enterprise Identity Mapping configuration from iNav in the bank’s network, but using Jack Henry’s IBM i to host the repository. Since Jack Henry had never set up SSO before, we used all the defaults and created two EIM registry definitions: thebank.com and jhasys.
Now it was time to test connecting a PC5250 Telnet session from the bank to Jack Henry. I was waiting in mild anticipation, believing it would work just fine. Unfortunately, the session displayed a sign-on screen! We checked and rechecked the usual culprits: PC5250 configuration and the QRMTSGN system value. These were set appropriately. We checked if there was a network router or firewall at the bank blocking ports. There were none. After banging our heads against the proverbial wall, the Jack Henry representative remembered he had an exit point program that would affect this. He made the necessary changes in a couple of minutes. We reran the PC5250 test and it connected with SSO just fine!
The next order of business was to populate EIM with the bank’s end users. The Jack Henry process for banks to create userIDs for their own employees on the Jack Henry system involves an administrator from the bank running a command supplied by Jack Henry. Jack Henry uses its own naming convention for userID names and does some other setup operations. The Jack Henry representative modified this program to use the EIM APIs to set up the EIM associations for the new user. Since only a handful of the bank’s users were configured with user IDs on the Jack Henry system, they were able to create the EIM entries for those users by hand.
From the bank’s perspective, the SSO configuration for the Jack Henry system was complete. From Jack Henry’s perspective there were still several tasks left. From my perspective I was excited as all get out because I knew I was about to be able to use some of the cool and robust security function we originally added to EIM many years ago, just for scenarios like this!
Secure SSO for Multiple Customers Accessing a Single Partition
Jack Henry wanted to be able to support multiple banks using SSO to connect to a single Jack Henry partition. Obviously, Jack Henry already supported this with robust security for existing customers — sans SSO. Jack Henry needed to ensure that SSO wouldn’t compromise any of this set up. From a security point of view, accessing a system through green screen sign-on via SSO has no effect on access control or security in general. But the data in EIM could be used to circumvent security if an attacker from one bank, for example could change their EIM association to a user profile for another bank.
This left us with two imperatives for securing EIM:
1) no bank EIM administrator should be able change anything in EIM except the ID associations in the EIM registry definition for that bank, and
2) no bank administrator should be able to see any ID mappings for (source or target) for any other banks.
Fortunately, EIM provides all of the security function to be able to handle this quickly and easily.
Here’s the configuration we used to do this.
First, we created an EIM user for Jack Henry to use to manage everything in EIM. We used the IBM Tivoli LDAP administrator interface to create a standard LDAP EIM Admin userID credential in the EIM LDAP subtree. Then we used the “Access control…” menu item from the EIM context menu in iNav to give this userID predefined “EIM Administrator” rights. The password for this userID will only be known by certain Jack Henry system administrators.
Next we created another LDAP userID credential to be used only for doing EIM mapping lookup operations. This userID is what the Jack Henry partition will use when it does mapping lookup operations at sign-on time. Again, nobody outside of Jack Henry will ever need to know or use this userID.
Finally, we needed to give each bank a way to manage the userIDs defined in the EIM registry definition for that bank. These associations are the source associations. For example if the bank’s Windows domain name is “thebank.com,” there will be an EIM registry definition named thebank.com. This is the only registry a bank can look at or change. If a bank wants to disable one of their users, for example, they could delete the source association for that user. If they wanted to change the Windows userID for someone, they can do that. They can also add a new source association, but they would have to run the Jack Henry new user setup program to get the target association.
We accomplished this by creating another LDAP credential for this particular bank. The EIM access control screen allows you to assign an EIM user to be the administrator of a specific user registry. So we gave this EIM userID rights to administer just “thebank.com” EIM registry definition and nothing else. We also had the bank set the password for this userID over a GoToMeeting session. Only a small number of people at the bank can connect to EIM with this userID — and then they are limited to only looking at the information in the bank’s user registry definition.
The High Availability Setup
The last task that Jack Henry had to do was to ensure that EIM and Kerberos data was handled correctly for its sophisticated high availability (HA) implementation. The requirement was to make sure that EIM was included in it. We chose to configure the Jack Henry HA software to handle any changes to the Kerberos configuration or Keytab files.
For EIM HA, we decided to use LDAP peer-to-peer replication. Doing this allows the LDAP server that underlies the EIM repository to automatically copy changes made in either the production or HA EIM repository to the other EIM repository. This is also done using the IBM Tivoli LDAP Administration interface. In my opinion, this is a lot more complicated than it should be. But, so be it.
Testing the HA Setup
A few weeks later we had the opportunity to test the HA for EIM and Kerberos setup. Jack Henry was moving a data center to a new location. During the move their customers would use the systems in Jack Henry’s backup data center. The bank was understandably concerned about availability in general and about SSO. The planned switchover happened in the wee hours of a Sunday morning. They wanted to make sure someone from BAI would be available to help with any problems. I assured them that BAI would be there for them and that I would be the one on call, secure in the knowledge that my baby, SSO, would work to perfection!
Right. Along about 3 AM the hot line rings. I had forgotten that this was the night of the cut over. But as soon as the phone rang, I knew what it was. “SSO isn’t working after the cutover,” the voice said. So I got on a GoToMeeting session with the bank and the Jack Henry representative. As soon as I saw the error message, I knew it was something to do with EIM. I was just a bit devastated. My baby didn’t seem to be measuring up.
Within literally a minute or two, we determined that the backup system’s EIM configuration (the data that tells the system the name of the EIM registry definition containing local userIDs) was wrong! We changed this to the right name and SSO began working perfectly once again.
I have a hypothesis as to why this happened but, understandably, neither the bank nor Jack Henry wanted to spend the time and money to fully test it. The important thing is that we found and fixed the culprit quickly, and I have another gotcha stored in memory for future implementations.
The Bottom Line
When all is said and done, what does this mean for IT shops using Kerberos and EIM for SSO? Well, for starters, Jack Henry Outlink Processing Service customers can continue to use or even start using SSO. It is also evidence that this approach to SSO holds up in high availability scenarios. It also shows that EIM was architected to be a robust solution both large and small customers. Finally, it shows how the EIM APIs can be used to integrate and automate the management of EIM with your existing identity management processes, procedures and programs.
If you want more information or if you want to implement SSO to your Jack Henry system (whether that system is internal or outsourced to Jack Henry), please contact me.
