Identity Management Success

Hello Everyone:

Several Internet Explorer 6.0 users (issue does not affect newer browsers,) have reported page display problems on our main site. We regret any inconvenience this may be causing our visitors. Until an Internet Explorer 6.0 referral page is provided, we ask that you consider visiting our main site using one of the following standards-compliant browsers:

• Firefox, 1.x or 2.x
• Apple Safari (any)
• Flock (any)
• Internet Explorer 7.0
• Opera 8.x or 9.x
• Konqueror

NOTE:  The Internet Explorer 6.0 issue does not affect the blog.

Updates will be posted when available.

Thanks for reading!

Blog Administrator
Links Business Group LLC

Hello Everyone:

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 IAM - related software (in no particular order.) As with any list of “gross generalities,” many exceptions apply. The point of this section is to honestly address some critical issues that vendor-related IAM websites, blogs, and podcasts will not discuss.

• 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 discontiguous, 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:

1. 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.
2. For Microsoft 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.
3. 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.
4. 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.)
5. 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.
6. 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.
7. 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.
8. 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.
9. 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.
10. 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 not which 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.
11. 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.

Conclusion

In summary, Identity Access Management (IAM / IdM) software installations must be managed like other aspects of your 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.

Have more questions? IAM software complexity and implementation issues putting the breaks on your program? Contact Links Business Group today at +1 877 769 8938 to schedule a complimentary initial consultation. Alternatively, you may log on to our contact page and submit a formal inquiry. Links Business Group responds to all questions and service inquiries within one business day.

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.

Hello Everyone:

We are pleased to announce our brand new website. Please visit http://www.linksbusinessgroup.com to experience the latest updates. Here are just a few of the new features:

• New contact and project request form. New clients and potential clients can visit http://www.linksbusinessgroup.com/contact_us.html and submit details directly. If you have "Digitcert.com" installed as a recognized certificate provider (we highly recommend that you support the independent certificate providers, such as this one) you can use the "https" option to submit the project inquiry form.
• New Service Listings. We will spare the marketing in this blog entry. Instead, we would rather you visit the site. From the smallest business, to the largest multinational, we have your data security, privacy, and IAM - related needs covered.
• All your favorite IAM / IdM / SSO and Identity Management Success RSS feeds are now in one place.
• Identity Access Management (IAM / IdM / SSO) Reading Room. A small, but growing compendium of documents covering both Links Business Group as a company, and pure IAM - related topics.
• Any many more. So don’t wait, visit the site today!

So, what is gone? Not much actually. We have maintained much of structure, while adding content, features, and changing the look. One feature that *is* gone is the old "Refer a Friend" feature. Among other reasons, we found that a few individuals were recently misusing the feature to send….shall we say….’uncivilized’ messages to others. Instead, we would ask that you refer your friends and professional associates directly to our main url, located at http://www.linksbusinessgroup.com.

One other quick update:  as previously mentioned, an increasing amount of content will be moved to the new site, and to the exclusive Identity Management Success mailing list. If you don’t want to miss out on any of our industry-leading content, be sure to stop by our main site and subscribe to the list.

Thanks to all of our clients, friends, and colleagues for helping make our first few years a great success! Please keep reading, and as always, contact us with any comments, questions, or content suggestions.

Best regards,

Corbin H. Links, and the Links Business Group Team.

Hello Everyone:

A major topic within our industry is Role Management/Engineering/Modeling/etc. So much has been written on the subject, that it can be difficult for true enterprise-grade organizations to separate fact from fiction, and find a starting point. What we tend to see all too often, is clients that feel that they are being compelled down the road to Separation of Duties (SoD), Role Based Access Control (RBAC), Role Based Management Frameworks, et al by external forces. Coupled with the deluge of available vendor documentation, the process of developing and using a roles framework can seem daunting or outright unachievable. Which model to use? Top down? Bottom up? Hybrid? Automated mining and mapping? In this article, I will attempt to share a few guidelines which may prove useful to organizations struggling to take control of their role infrastructure..

Why Roles?

To answer in the negative “why not roles,” roles should not be created in response to pressures external to your organization. If an outside auditor has to tell you that you need roles, compliance, and separation of duties, then you have bigger organizational challenges to worry about. On the bright side, organizations do have this in place already. The real issue is mapping the relationships between people and roles, roles with other roles, and roles to the organization.

To answer in the positive, use roles to model and understand your business. Use roles to manage appropriateness of access. Use roles to streamline process, reduce time to market, and reduce risk. Use roles to standardize your business. Use roles to manage application entitlements.

What is a role?

A group of tasks that can achieve a consistent result or results. For example, an HR Administrator has a certain set of tasks that she performs every day, which result in people being hired or right-sized. These tasks can be collectively grouped into a role, or role definition which can be assigned to an individual, or a grouping of people. Roles should be thought of as collections of business tasks, irrespective of access control requirements. (We’ll get to that later.)

What is a group?

A group is a collection of people or objects (printers, computers, etc.) that are grouped together for the purpose of host or system-specific permissions controls. Examples include Microsoft Active Directory groups, UNIX groups and group files, and permissions groups in Database Management Systems. Groups, or large collections of groups, are often used to implement quasi-role definitions within host devices, applications, and operating systems. NOTE: Most organizations use large collections of groups to define singular roles.

Types of Roles

Links Business Group LLC recognizes two broad categories of roles:

1. Business/HR Roles (May be referred to as functional roles or coarse-grained roles as well)
2. Application/Resource Roles (May be referred to as structural roles)

Business/HR Roles are generally defined by classifications from the business HR system, such as SAP or Oracle. Examples might include “Payroll Clerk” or “Investments Analyst” These roles can be viewed as the “top” in the “Top Down” role modeling approach. “Top Down” is considered strategic.

Application/Resource Roles are generally defined as collections of policies or permissions which determine access to applications or systems. These roles may be also viewed as the “bottom” as in the “bottom up” role engineering approach. “Bottom Up” is considered tactical.

Hybrid is used in different ways. In role modeling, it refers to a combination approach toward achieving an enterprise-wide Role Framework. Role information can be extracted from applications, operating systems, and other sources, while HR-based Roles are used as broad categorical definitions. Between the two, a middle ground is achieved.

Hybrid is also used to define individuals who may serve completely disparate roles within an organization. For instance, someone that is a Production Systems Administrator Monday through Thursday, and a QA Administrator Friday through Sunday.

Approaches To Role Modeling

The following diagram depicts three primary role discovery and engineering practice models.

In our view, the hybrid model is the best for most situations. It really depends on how far along your organization is in the role discovery, and engineering process. If you have clean data to work with, then you can start mining upwards, while strategically defining roles downwards. On the other hand, if the process has not yet begun, then you may have to start at the bottom and “mine upwards” for a while to understand the true relationships between people, tasks, systems, and data. (Hint: Links Business Group LLC can help you with this…)

The Good News: You may be farther along than you think

Audit reports can be disheartening, daunting, and discouraging (not to mention extremely time-consuming and expensive.) The key is to not let this temporary pain drive you toward more tactical solutions and one-off tool purchases. In general, tactical solutions will only lead you further away from a cohesive role framework, while ensuring that your audit pains will be ongoing. The good news is that most of your role information already exists. It exists in your HR databases and various sources of identity such as databases and directory servers. Make plans today to go after the data in any way possible, while realizing that it may be necessary to break some existing processes to connect your data stores to one another and begin the extraction. This often results in two separate project threads: one thread to create a role model for today, the other thread to create a role for tomorrow. You will need both, so plan accordingly.

What Do Enterprises Need to Do?

• Start with the end in mind. With role modeling, the end goal is to understand and improve your business, and how your employees, partners, suppliers, and clients interact with it. (Notice how I did not say “comply with an audit finding”)
• Centralize and clean your data. There are many strategies for this, but the primary thing is to get started, and build a repository for understanding roles and role relationships. There are some great tools in the IAM Space which can help make shorter work of this task (we can help you there too..), but in the end it still must be viewed as a business process exercise, not a technical tools exercise. The data gleaned from this exercise, will serve as the input to your future IAM-related projects, such as enterprise business process management (BPM), and centralized directory services.
• Start the top-down portion with your job titles, job codes, or related terms as they pertain to your HR classifications. This helps get you to the “To Be” or desired “Future State.” These coarse-grained roles, will help define the finer-grained roles and application entitlements required by your software and computer systems.
• Be strategic when mining from the bottom up. Role mining, mapping, and reporting is a significant endeavor (read: thousands of hours and potentially dozens of resources) for the larger enterprises. Make the effort count, and plan to do it only once, while building in the flexibility to accommodate the constantly changing business climate. There are some great tools which can dramatically reduce the work required for role mining, engineering, and management.
• By all means implement short-term tactical solutions to solve current audit emergencies, but do not build in new reliance on these tools. Remember, most organizations have issues because they have too many role tools, not too few.
• Once the models are discovered, designed and ready for implementation, stop and understand what your existing IAM Infrastructure can provide — and what it cannot. The gap between provisioning, auditing, compliance, role mining, integration, and access management tools can be quite significant. Provisioning and Access Management solutions can help spread the mayonnaise (see below,) but may not help you to extract and build a solid enterprise role model.
• Design your roles hierarchy into a centralized Directory Service. In most cases, enterprise roles come long after the initial Directory Service has been designed and implemented. Take this opportunity to build a role-centric model into a new enterprise directory service.
• Publish the roles, and make them easily accessible, relevant, and reusable. See the previous point. Publishing roles in the form of Directory Services, databases, and web services (just to name a few,) will help ensure longevity of the new model while promoting consistent security frameworks within the organization.

But what if I do need to comply with audit findings and enforce Separation of Duties…right now…today…?

The answer: Role Mayonnaise. No…not the food. It is one of the terms we use to describe the approach of putting role management in place by super-imposing (i.e. spreading) a role management framework over the top of your existing systems and applications, while masking the flavor of existing current security and role models. Similar to the virtual directory approach. Spreading the mayonnaise is where provisioning tools come in. The best provisioning tools out there today can help make (relatively…) short work of spreading role mayonnaise over your existing infrastructure. Remember though: this is only a first tactical step to satisfy very short-term requirements. Longer term, your provisioning tools will become part of the implementation platform for your entire IAM Strategic Framework.

Conclusion

Role discovery/mining, engineering/design, and implementation are critical exercises in the life of your IAM Program. Though this article just scratches the surface, following the time-tested guidelines above can propel your organization far ahead of those that are deep in the trenches and struggling with roles. Strong, useful, auditable, and reusable role frameworks are highly achievable for organizations that are committed to achieving them.

Still have questions or want additional perspective on IAM Success? Please send email, or call us at +1 877 769 8938. Thanks for reading, and 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.