Recently I wrote an article called Practical Uses for Enterprise Identity Mapping that appeared in IBM Systems Magazine’s AIX Extra online newsletter. It described ways to use EIM to solve problems unrelated to Single Sign-On (SSO).
More recently, I discovered that another IBM i ISV had added support for SSO to their Web-based application.
I was excited to learn this… until I looked at the details.
While the vendor seemed to understand the ideas behind EIM related to Windows userIDs and IBM i user profiles, digging deeper into the implementation showed that they didn’t understand the foundation concepts behind EIM.
They are just the latest example of the misunderstanding surrounding EIM.
I’m not trying to pick on this particular ISV. I appreciate their attempt to support SSO. But they did make what I consider to be a big mistake.
As I understand it, in their web-based application you can use IBM i user profiles or userIDs that are defined in their application. It appears that to map from the Windows userID in the Kerberos ticket to the IBM i ID, they rely on EIM. This makes total sense as this support is built into the Apache webserver.
However, to map from the Kerberos ticket to the application userID, they introduce a different mapping technique. Once the IBM i user profile is mapped, they switch to a proprietary and system-specific file to map the IBM i user profile to the application userID.
In my opinion, this was their mistake. They could have used EIM to do the same thing. This would have been better for a couple of reasons.
- First, administrators would not have had to learn yet another way to manage some aspect of identity mapping.
- Second, using EIM would allow the mapping to be used across multiple Apache instances.
So what’s this have to do with how EIM can be used for non-SSO stuff? Well, the primary message is that EIM can be used in a number of ways that the average developer wouldn’t think about. They include both SSO and non-SSO objectives.
I must admit, if anyone is to blame for the poor understanding of EIM, it is IBM and — to a greater degree — me, since I was the architect and should have paid much more attention to external communication about EIM.
The article in the AIX Extra newsletter and this one are an attempt to get a little more information about EIM out there. Hope you find them useful!
