Understanding and Planning for Access Management Issues
Understanding and Planning for Access Management Issues
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:
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.)
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.
Importance of Database Management Services Reputation Management - How Important Is It? Debt Management Uk Debt Consolidation Help Content Management System Spa Management Training Takes You Far The Forex Money Management Calculator Project Management: The Science Of Execution How To Establish Effective Communication Between Employees And Management? The Five Secrets To Effective Time Management Time Management Is A Myth three Things To Check While Hiring Pay Per Click Management Services five Mistakes to Avoid PPC Campaign Management Ensure All Your Events Are Successful With Event Management Services