Identity Management Success

Dear Readers:

What is happening: The Links Business Group Website and Blog will be undergoing maintenance and feature updates.

Scheduled maintenance window: Saturday, 12/22/2007, 5am to 6pm PST

Sites affected: http://www.linksbusinessgroup.com and http://www.linksbusinessgroup.com/blog

What to expect: Content in both locations should remain available during the maintenance window, but may not appear correctly in your browser. (Regardless of browser type.)

Questions? Please mail “info ‘at’ linksbusinessgroup.com”

Site Administrator,
Links Business Group LLC

Hello Everyone!

Today I write the traditional “Year End” and “Coming Year” post. (Members of our Identity Management Success list will receive a separate mailing early next year.) This year I decided not to do a “predictions” post, and instead take a moment to share a few thoughts about our company, and Strategic IAM.

As a company, Links Business Group enjoyed a strong 2007 and looks forward to an even bigger 2008. The last 12 months have been a great and exciting time, and we want to give all of our readers, clients and partners a hearty “THANK YOU” for your continued help and support. As readers of our website and blog, you know that we are client and market driven, so we owe much of our success to the tips, suggestions, and feedback received. Please keep those suggestions coming!

What’s in store for the coming months?

• New website, and even more of the quality content you’ve come to expect from Links Business Group
• Announcement about our new offices (that will come separately)
• Expanded members-only exclusive offers and community features
• New services, and expansion of our existing services
• Increased channel presence and expanded partnerships
• Online store
• Increased expansion of our Business Consulting and Strategic IT Services business
• And a few nice surprises along the way….

But what about the future of IAM and Strategic IT?

Well, I did promise ‘no predictions.’ Part of the reason is that IAM, as with any Strategic Business endeavor, is a continuum. Life, the world, businesses, organizations - none exist within neat, fixed blocks of time. Certainly, the global market place does not exist in a vacuum or even recognize the same annual calendar. Thus, it seems more realistic to view things in an evolutionary way. Organizations simply exist in different stages along the IAM Continuum. Some are very early stage (”We need some security / auditing / reporting, what do we do?”), some are in the middle stages (”We have security awareness, processes, and systems, but need to do something more useful and business relevant with them”) and some are moving to more advanced stages (”We have strategies, security, frameworks, processes, and the right people and are actively using/re-using our information as a strategic asset to drive growth and customer satisfaction. We know where our users go and what they do, we know where our clients go and what they do, partners, suppliers, etc. We are able to leverage the collective knowledge of these connections and experiences into a strategic knowledge tool on which our organization depends.”) The stage beyond “advanced” is one in which multiple advanced stage organizations collaborate to drive untold innovation, change, and client/customer satisfaction. Where is your organization in this timeline? Where does it want to be? Answering those questions or better yet — helping you get to the next stage in real-word terms — is where we can help.

In respect to tools and technologies, the marketplace is incredibly rich. There are more tools than ever that can be used individually or collectively to grow and manage your organization. Of course, people and process must come first, but tools and frameworks can speed and refine the processes, or take them to new levels. We continue to keep our eyes trained on the technology market, and work to ensure that clients do not become vendor or “technology locked” into any given tool or platform. One thing I will say about the future, the technology market which has always moved very quickly, is approaching fever pitch. The largest vendors get larger, and the smaller ones jockey for position or acquisition. Consider calling us for a complimentary consultation.

Clarify “Vendor Neutrality” - Does this mean that Links Business Group does not partner?

We receive frequent questions about our neutrality stance, so I will attempt to clarify. ‘Vendor neutrality’ simply means that we do not force clients down any particular path or vendor toolset. Nor are we beholden to large vendors to provide us with leads or product-specific contract opportunities. However, that is not intended to imply that we will not recommend what we feel is the appropriate mix of solutions for our individual clients. Links Business Group’s ability to provide its clients with top-notch answers and solutions to real-world challenges and opportunities, requires a strong network of partners and affiliates. Our rolodex is filled (and growing) with quality service providers and vendors which share our passion for client advocacy. If you belong to an organization that believes in our code of ethics, please visit our partnership URL for more information regarding partnership opportunities.

Final note before January 2008

This is my last blog entry before early January, so let me take this opportunity to wish all of you a safe and prosperous 2008!! Thanks again for reading, and if you find the information useful, please consider linking to us.

Until next time, wishing you all the best, of Identity Management Success

Corbin H. Links, and the Links Business Group Team

©2003-2007 Links Business Group LLC. All rights reserved.

Hello Everyone:

Issue resolved, blog and RSS URL’s are back and functioning correctly. Thank you for your patience.

Blog Administrator,
Links Business Group LLC

Hello Everyone:

Our ISP is currently experiencing difficulties. Some blog links, particularly the RSS feed links are temporarily out of service.

We are working with the ISP to resolve this issue and will sened a status as soon as we know more. In the meantime, please continue to visit our main site. Thank you for your patience.

Blog Administrator,
Links Business Group LLC

So you are thinking about, ready to, or have implemented “SSO”. Now just log in, and watch the user satisfaction numbers roll in as your clients and users seamlessly point and click their way through your entire application portfolio, without logging in a second time. Piece of cake right? Wrong. To this day there are still organizations that believe this, and SSO/WAM/Access Control vendors do not always help this situation.

I thought it might be useful and share a few “thoughts from the field” regarding SSO and access management planning, and the types of issues that frequently arise. This post is intended more as a “get the information out there” type of post, so each identified issue may not include a comprehensive mitigation plan. Furthermore, this is only a partial list which attempts to outline some of the most *common* issues. For detailed help with these and other issues related to Access Management and IAM, please contact us.

Background:

Today, we’re talking about the “AM” or “Access Management” component of the “IAM.” There are two components we’ll discuss. The first is the technical/implementation piece. This set of issues can affect most any full Access Management implementation, regardless of vendor or product.

The second component is the end-user or client perspective. In a large organization which has traditionally been comprised of client/server applications, making the transition to “browser as universal application client” can require significant shifts in organizational thinking and user behavior.

Technical / Implementation Issues

• Computer clocks not in sync. Time variations between servers, and servers and clients. Time sync, especially for Kerberos-based implementations (AD, etc) can stop SSO implementations before they get started
• DNS issues. Hosts do not resolve properly, within their given domain. For instance, “myserver.client.com” might actually resolve to “myexcellentserver.client.com” If an access management/SSO token generator is unable to properly resolve a host name, it will not allow a session — or a token to be passed to the user or application that requested it. For practical purposes, we are talking about DNS “A” records, not CNAME, MX, and other record types. The tools “nslookup” or “dig” (there are others as well) are your best friends here. This next point is so important, and so common, that it’s worthy of full bold type: always, always, always DNS validate your servers against each other, and especially to and from the Access Management host. Running a quick ‘nslookup’ from your desktop is not enough. The tool must be run from your Access Management server to validate any servers that are connecting to it. If it resolves as above, Access Management and SSO *will* invariably break.
• Token profile issues. Applications, or federation partners that have a mismatch between their token types or profiles, and the ones you have enabled.
• Certificates (x.509) implementation issues. Expiration issues, wildcard domain card implementation issues, distribution issues, revocation issues, client support issues, certificate import/export issues. Now that we start talking about it, probably several posts could be written on x.509 alone!
• Trust issues between Kerberos realms. Realizing broad, and successful SSO implementations require seamless Identity token passing between systems that really were not designed to share tokens in the first place. Just like adding routers and hops makes for greater network and protocol complexity, getting disparate realms to “trust” each other requires a lot of planning and compatibility testing. This issue is somewhat mitigated in heterogeneous Active Directory based environments, but becomes more complex when adding other Kerberos-based hosts, or Federation strategies to the mix.
• Realm integration issues between Access Management Tools and Application Servers. In the Java world, realms on application servers can often support externalized authenticators such as LDAP, Active Directory, or third-party IAM tools. Integrating one or more different types of authenticators can be a technical challenge, and require extensive debugging.
• Multiple authenticator and authenticator chaining issues. Access Management brings great power and flexibility to the IAM process. One of both the greatest things, and the worst pains, is chaining multiple different types of authenticator together to complete a transaction. For instance, chaining LDAP, Active Directory, and UNIX-based files authentication.
• Policy resolution issues. Access Management tools require policies, which determine what can be accessed on the server, who can access it, and what methods of access (i.e. “URL accepts Active Directory credential / URL policy does not allow forms-based login or simple username/password pairs) are allowed. Policies implement or make use of roles, users, “principal” mappings and the like. It is not uncommon to spend hours or longer troubleshooting even basic policies.
• LDAP Server Support Issues. Access Management tools almost invariably use, or are capable of using, an LDAP server to store credential information, roles, policies, and configuration information used by the Access Management tool. However, it is important to plan for that new found relationship. For instance, are LDAP schema modifications required? How will the schema modifications affect your existing LDAP-aware applications and infrastructure? What new schema attributes must now be added to your provisioning templates so that new users, groups, roles, are recognizable?

Client / User Issues

• Change in browser use behavior. Browsers may display new portal-based login screens, or present new options such as password reset that they are not used to seeing in the browser. Most users are very ingrained in using their browsers for just a handful of applications, but a lot of websites. One of the biggest changes for users — especially in SSO implementations — is that they have to get used to the expiring credential, or a credential/token that goes away when they close the browser. This can result in a *huge* behavioral shift for many organizations. From a pure browser perspective, most Access Management/SSO tools consider all browsers to be the same. Universal cache, with a single token. Tabbed browsers *may or may not maintain consistent token state between applications.* With Internet Explorer 6.0, there was no tabbed browsing, so users just opened and closed the browser at will. Well, with the implementation of Access Management and SSO, that behavior has to change. Logging out of a site and closing a browser for instance, can “kill” the user’s SSO token, requiring a new login the next time a resource is visited. Browser, token/cookie, and login/logout behavior *is* highly configurable for most sophisticated Access Management / SSO tools.
• Change in application interface. The thick, rich, 1990’s era quasi-Motif/Windows 3.1ish type of interface is now changing to a browser, and a certain look and feel. What’s more, the html/browser-as-application-interface era has ushered a new opportunity to make multiple applications to look and feel *as much unlike each other as possible*.
• Change in users expectations for where they can go, and how long they can stay before their credentials expire
• Changes in password complexity policy. Invariably (but with exception,) organizational Access Management directives bring changes in existing password policies. Passwords may become more complex, or even go away if biometrics, certificates, SecurID tokens are adopted. When used in conjunction with a browser, the user complexity threshold has multiplied considerably. Plan significant communication with your users, and your helpdesk who will be taking a lot more calls (at least in the short term) to help users adjust to the fact that they may be changing their passwords more frequently, or no longer using their pet’s name to log on to their HR benefits portal.
• Change in user password management patterns. This is interesting, because Access Management often involves its close relative, the “I” in IAM, or “Identity Management / provisioning / user self service.” The idea is that the pre-SSO network user was in the habit of constantly maintaining and changing dozens of passwords. In the post-SSO network, the user now may be going to a single portal address to change a password for a great many applications. It is crucial to the success of your program to get this step right, because this is one of your user’s few “interaction points” with your Identity solution. In many organizations, perception is 90% of the law.
• (Possible) changes in authenticator. This is the user side of the Technical Implementation issues discussed above. A fairly common vision within organizations implementing Access Management is the “selectable authentication” model, or “cafeteria style.” The idea, is that the user can choose one or more different ways he or she wishes to authenticate to the system.
• Dealing with unexpected SSL/certificate errors. We’ve all run into this. Errors (often invalid) stating that there is a domain mismatch, or that the certificate authority is “unrecognized” in Internet Explorer. This behavior can be extremely confusing to users and generate a ton of calls. Many organizations set up self-signed certificates, or their own Certificate Authorities. Unfortunately, this new found capability does not always translate to the end-user browser, where there may be old information, or the certificate stores *on each and every user’s image of the browser* have not been updated to accept the new certificates.

Summary

We’ve covered a fair amount of ground here, but it really is just the beginning. From my perspective, there are two key things to take away from this article:

1. Plan for the known issues before you have them. This includes building time into your project plans to deal with both the expected and the unexpected. Any one of the issues above can take anywhere from several hours to days or weeks to resolve in large environments. Some of the user behavior pattern issues can take months or even 1-2 years to address. We recommend completing an IAM Readiness plan before even considering an implementation. (We work through this with you.)
2. Engage end-users and technical team members early in the process, so they can understand the potential issues. Also give strong consideration to receiving outside readiness verification. Often, especially in strongly politically-focused organizations, technical teams will gloss over potential infrastructure issues that could lead to many IAM implementation issues. It is highly beneficial to request outside assistance and advice from people that really understand these issues and can help pave the way.

Thanks for reading! Until next time, All the Best, of Identity Management Success.

Corbin H. Links, President
Links Business Group LLC

©2003-2007 Links Business Group LLC. All rights reserved.