|
As we end another traditional break here in the states, it might be useful to ponder real-world IAM software implementation issues. Originally, I had thought of doing a "timeline" type of post regarding IAM software, but on further review it seemed more germane to focus on IAM software problems.
First, a few "gross generalities" about Identity Access Management (IAM) software (in no particular order):
Vendors do not always put their best people on IAM-related accounts. Of course, this depends heavily on many factors, which is why I use the term "generally." The best and brightest - the engineers, developers, key strategists, and frankly many of the people you run into in the 'blogosphere' on company blogs do not actually implement IAM software. So who comes to your site? Partners, offshore hires, trainees, sales people (or "sales engineers,") High-dollar accounts are certainly more likely to get the talent, but even those accounts can suffer in this stretched IAM market.
IAM software is inherently incredibly complex - by nature and design. It cannot be expected to have been exhaustively tested in all permutations of environment, version, operating system, DNS, certificates, mixed authenticators, etc. I could repeat this point a thousand times. Note to enterprises - most IAM software, especially "suites" are essentially service offerings, as opposed to real packaged products. They may start off life as a retail package, but must be heavily tested, customized, configured, developed, extended, and tuned for real-world enterprise environments. That is the reality of software in the Identity Access Management space. Please do not expect point and click configuration for true enterprise-class software. It is not only an unrealistic expectation, but can lead to all sorts of planning and budgeting shortfalls when it comes time to implement, extend, and maintain.
IAM Software is often tightly coupled to specific versions of operating systems, web servers, application servers, and related components. In fairness to the large vendors, imagine trying to get a product to market in which it has to be supported on "n" number of platforms, with the multiplier effect coming into play when one considers the raw number of other systems or 'targets' that the software must connect with. Don't let the "open platform" vendor story fool you. Your JDK versions, OS revision level (down to the service pack/patch number) in some cases, can make or break your key IAM components.
Vendors do not generally put their best support people on the phones, or behind portal-based support queues to support you. Most all the major IAM vendors (probably all of them, but I'll hedge and say 'probably' ) offshore significant portions of their software support. Certainly most do, as we have experienced first hand time and time again. A discussion of the merits (or not) of offshoring is best left to the pundits. My point here is that it does occur often, it's a fact of life with enterprise software vendors, and one can reasonably expect communication, skill deltas, and time zone issues (among others) when seeking basic product support from IAM vendors.
IAM support people are not necessarily up to speed on all the latest versions and permutations of their own products. This is an area of wide variance in the vendor space. However, generally speaking, a support call can travel through many hands before arriving at a satisfactory resolution. For vendors with very frequent revision cycles, it can be virtually assumed that a good portion of the support staff is not fully up to speed on the latest versions. Additionally, attaching firm ownership of a support case can be daunting, and extremely frustrating to enterprise clients. (Or, anyone else for that matter.) On a related note, vendors - like airlines and health clubs - tend to oversell their resources. They are more than happy to sell you all the product you want, with grand support promises, but at the end of the day they do not have the resources to support what they have sold. This is a classic problem, and one that Links Business Group sees as going unresolved in the foreseeable future.
As with any chain, IAM software is only as good as its weakest link or connection. The best software package in the world can only be responsible for its internal operation, and not for fixing the operation of connected components. Case in point - databases and operating systems. IAM infrastructure can be an enabler, can provide features and functions that do not yet exist, and provide a platform for services. But organizations have many disjointed services and repositories of information that are in various states of disarray, older versions, misconfiguration, or dirty/unstructured data.
Successful IAM Software implementation requires a team. Minimally, this will include one or more technical implementers from the vendor, and one or more subject matter experts from the client site. Subject Matter Experts must be true experts on their target platforms and the data residing on those platforms for IAM software to have a prayer of success.
Many IAM Vendors have "Frankensteined" (if that can be used as a verb) various IAM software packages to create a presence in the IAM space. No names are necessary here. Anyone in this space and all of our clients know exactly what I'm talking about. Going back to the complexity point, consider the logistics of bringing three or four completely discontinuous, unrelated countries together to form a united whole. Not easy is it? Ok, granted IAM software is not *that* complex and the point is somewhat exaggerated for dramatic effect, but you get the point. When cobbling together various parts of machinery to make new machinery, brand new complexities and problems will occur. Putting together a team of people that can successfully put all the pieces together at a live client site is an extreme challenge for most any vendor.
So what can (and will) go wrong with IAM software? Here is a highly shortened list....
Installation failures. Frightfully common, for a wide variety of reasons, including faulty installation scripts, library/file issues, version conflicts, etc. See "dependency failures" below for more detail.
Authentication failures.
Authorization failures.
Connection failures.
Dependency failures (other software, versions, missing libraries and JAVA classpaths, missing patches, or patches supersede an older but more "supported" configuration)
Weak-link encryption. In this scenario, some portions of the Identity transaction may be encrypted, but others are not.
Database read failures. (Bad connection strings, databases that require extensive JDBC string tuning such as character translation, etc...)
Database misread failures. Your tables say one thing, the provisioning tool which is connected to the database says something else...
SSO Failures. User logs in, the token is granted, user wants to take token to other portal/application/website and 'seamlessly' login. Often, not so seamless especially when multiple products are involved in the transaction.
Directory Service attribute mismatch.
Java Library Errors. May not be related to installation, but starting/stopping of IAM components or application servers.
Function errors. Three quarters of the way into the transaction, strange errors emerge....
Module or plugin mismatch. The version of a previous plugin or module which was certified for a previous version suddenly fails with the new one, only to find that the particular plugin that your site relies on was not thoroughly tested...
SSL / Certificate failures. Certificate authority may be in the certificate cache of your web server, Java application server, or client browser. Magnify the situation for environments that also require client-side certificates.
There are many others, but these are just a few of the many things which can keep Identity Access Management component installations from fulfilling their intended mission. (And earning back some of the significant monies your enterprise has spent on them.)
Is there hope?
Yes there is. Here are a few (far from inclusive) suggestions that can *help* ensure that your Identity Access Management software installation and maintenance has the best chance of success:
Standardize on a JDK version, and plan to stick with it for at least 1 full implementation cycle. It is very easy (and tempting) to continually upgrade JDK and JRE components as new ones come available. However, doing so can create compatibility issues with your IAM software. Stick with the version that your software is certified with, and if certified with multiple versions, go with the latest. That said, *always* go with at least version 1.5.x, due to the myriad of security and security model enhancements that are now available. Vendors will patch based on older JDK's as well, so don't assume that that an upgrade is automatically required to fix a particular problem.
For Microsoft (TM) shops, or heterogeneous environments with Windows 2k3 servers and XP or Vista clients, plan a move to.NET 3.0. We have discussed this elsewhere, but it is an important point. Not only are there useful new IAM-related features, but.NET is *in general* backwards compatible with previous versions, while adding important fixes and enhancements. CardSpace support is also a key driver for moving toward.NET 3.0.
Standardize JDBC drivers on a specific version, and ensure that the Identity Access Management vendor will certify said version for connectivity with your data sources. IAM vendors, especially of provisioning and audit tools, rely heavily on JDBC connections to directory services and databases. Their products are often coded to expect a certain class or version of driver. In the case of JDBC, newer is not always better. I repeat "newer is not always better, when it comes to JDBC." Remember also that many components of your IAM software may rely on the same driver, so mixing and matching versions can be a major source of grief.
With the big vendors, get a clear picture of their product roadmaps for the next 3 years. Remember that Identity Access Management programs are multiyear endeavors. If they cannot provide one, it generally means that they're just waiting to see what others are doing in the space, then going on an acquisition spree. (We won't mention names.)
With the small vendors, get a clear picture of their exit strategy, and request source escrow. Admittedly, many small vendors may not part with this information and may not have a really long term plan. No problem with that in and of itself, but with the blistering acquisition rate in this industry, it is critical to know where these companies stand. Talk to the president. Talk to the board (if applicable.) I cannot tell you how many established "smaller" vendors we have spoken with and asked these point blank questions, only to see them be acquired in the next few weeks.
Review implementation scenarios with the vendor's technical people and see how they respond. Repeat with their service. Perform a couple of test service calls during the product evaluation phase. Insist on having access to full support doing evaluation. Call them during the business day, then call them at 2:00am in the morning. Ask the same question each time. Compare and contrast.
Request virtual disks of vendor software to test. Look at the libraries loaded with the application servers and web servers. Capture and review the logs. Check for inconsistencies.
Request...no...*demand* a consistent implementation team. Large enterprises have to deal with enough resource challenges without having to worry about which vendor representative will be showing up at a site, or sending global emails to your technical team asking about VPN passwords or troubleshooting access issues to your environment. Get a consistent team together up front, allow for a 2 - 3 person change "contingency," and get this written into the contract.
When your product and/or product suite is ultimately selected, pick a good cross-functional mix of your Subject Matter Experts (SME's) and send them to IAM product training. More importantly, *make sure that the SME's going to training are planning to *stay with the project.* Key SME's must be comfortable with, and understand your IAM products, especially as they relate to connecting with SME-controlled resources.
Put together a comprehensive listing of all your application authenticators: databases, directory services, XML blobs, flat files, or wherever IAM data resides in your enterprise. Present it as a checklist to your IAM vendor, and ask them to specifically detail how their product(s) will address each one, and also those they cannot. While this may sound like a trivial exercise, for many large enterprises, finding out exactly what they have, much less how they can protect what they have, is a vast exercise. The collection and collation of this data is not up to your vendor's IAM implementation team. Please do not expect them to get this for you. Rather, please plan to have this ready for them before implementation starts. Often, a key detail or pattern will arise during the portfolio review phase, which can be fundamental to deciding the best architecture and implementation plan for your environment.
Maintain a strong code/software management practice. If you do not have one in place, get one before you embark on multi-product IAM implementations. Structure your code repository by product and project, and keep in mind that access management and provisioning products make extensive changes to directory services and databases. Match each update to a particular build or revision of your IAM software components.
Article Summary
In summary, Identity Access Management (IAM / IdM) software installations must be managed like other aspects of your Identity Access Management (IAM) Program. Plan for the complexities of IAM software, and most importantly, take small baby steps with each software tool. Avoid jumping in with certificates, complex password policies, Federation, complex database and directory joins until you have a clear test plan in place, and can validate basic product functionality. Once validated in your environment, move very incrementally up the feature ladder until your use cases are fully satisfied.
About the Author
Corbin Links is known in professional circles as "The Consultant's Consultant." He is the author of three books "IAM Success Tips: Volume I," "IAM Success Tips: Volume II," and "IAM Success Tips: Volume III." Corbin is currently writing his fourth book, which is due for release in October 2010.
Join the Identity Management Success Revolution at http://www.linksbusinessgroup.com
|
Print article
Bookmark this page