Chapter 19. Identity Management Reference Architectures
When I was CTO at http://iMall.com, we were frequently pushing technology envelopes. A lot of the web technology that people take for granted now—such as application servers, templating frameworks, and even relational databases—were either not available or not widely used in building web sites. At the same time, new technologies were being developed at breakneck speed as people tried to create the scaffolding on which the World Wide Web would ultimately be erected.
As CTO, part of my job was to develop an overall technical strategy for the company and decide not only what products we’d build, but how we’d build them. I found that just picking a technology wasn’t enough. Even if I understood the technology well and could see how it would fit into our overall system, communicating that vision to the system architects and developers was difficult. What I found myself doing, over and over again, was building a small pilot project that showed how a particular technology worked, how it fit into the suite of other technology choices we’d made, and why it was beneficial. There’s something about a real design and working code that grounds a technology choice and makes it real.
The last six chapters have shown you how to create an IMA for your organization that guides design and implementation so as to encourage interoperability. In Chapter 17, we saw how an identity interoperability framework, using a formal process, can make technology choices. Beyond merely making technology choices, however, an IMA should also put those technologies in perspective in the same way that my experiments did for iMall. Doing so will help system architects and software developers understand how their designs fit within the overall identity management strategy.
Reference Architectures
I didn’t realize it at the time, but what I was doing at iMall was creating informal reference architectures (RA). A reference architecture is a diagram or set of diagrams that shows the distribution of system functions among components in the identity infrastructure and provides a topographical map for how those functions relate to each other. Reference architectures do not give the design for an actual system or even a detailed diagram of how those systems interact, but rather provide architectural guidance and best practice information for practitioners. The reference architecture provides technical practitioners and business planners a goal state and gives a clear picture of the infrastructure that the enterprise is building.
This chapter will present the outline of a very general reference architecture for a digital identity infrastructure. As part of building your IMA, you should adapt this reference architecture to your own needs and circumstances. This chapter will also show you how to do that.
Benefits and Pitfalls
An RA has a number of benefits for the enterprise:
Shows system architects the recommended way to structure systems.
Shows how systems tie into the larger enterprise infrastructure and put system architecture decisions in context with respect to the enterprise-wide system.
Shows how enterprise components, like directories, should be used.
Captures best practice information for system architectures.
Makes training easier because new developers can be educated using the RA. Moreover, developers transferring from project to project come up to speed more quickly because the architecture is familiar.
In addition to the benefits, RAs pose a few pitfalls :
RAs can be overkill for some projects.
RAs may stifle creative and innovative solutions to problems.
The most effective way to mitigate these downsides is to remember that an RA should never be followed by rote. A reference architecture should be evaluated for each use and proven in practice. As a component of the IMA, the RA should be subjected to the same feedback cycle shown in Figure 14-1 as other IMA components. The feedback may change the project, or it may change the RA. Feedback on how well a particular RA worked in a project is likely to affect foundational components in the IMA such as the interoperability framework (IF) as well.
One way to use an RA in a project is to adopt it piecemeal and iteratively as needed. In this practice, the project uses the RA as a reference, but only implements a subset of the architecture because of specific project needs. For example, the RA might contain multiple servers and a load balancer to create a high availability environment, but in practice, the project leaves out the load balancer and uses only one server, because high availability is not a critical factor in this particular application.
Reference Architecture Best Practices
As you develop reference architectures for use in you organization, there are several best practices that you should keep in mind.
- Use the governance process
An RA is a component of the IMA and is subject to the same governance process as any other IMA component. This implies that the RA is reviewed frequently and updated as necessary.
- Customize
A reference architecture should be customized to fit the organization. As we’ll see, what we’re calling “the” reference architecture can actually be a collection of architectural recommendations. Each recommendation should be specific to problems that your organization is facing and be the basis for systems that you care about in your business.
- Implement incrementally
As we saw, in mitigating pitfalls, RAs frequently needed to be used in a piecemeal fashion. A good RA should be designed so that it can be scaled and customized to fit project needs. Recommendations for scaling and customization should be included in the RA documentation to guide system architects and developers in its application.
- Prove in a pilot
Ideally, RAs are tested in a pilot scenario and retested whenever components or practices are changed. The pilot implementation should be used to test new components or practices before they are broadly recommended. Small organizations may not have the capacity to do this in a formal way and may need to rely on vendor studies, third-party analysis, or small pilot programs to verify technology combinations. Larger organizations may be able to develop formal reference architecture validity programs as part of their IT research arm or the CIO’s office.
- Experiment
RAs for systems typically contain specific recommendations about hardware and software components. The interoperability framework says what’s allowed, but the RA says what’s recommended and which combinations work well together in the enterprise system. Innovative project teams may choose to swap out some of the recommended software or hardware choices for compatible choices. There should be a process in place for feeding this valuable experimental data back into the reference architecture so that projects can benefit from the experience of other projects.
Using a Reference Architecture
Small organizations may have a single reference architecture that represents the enterprise digital identity infrastructure. In this scenario, system architects use the RA to find out how to connect to and use the enterprise infrastructure. For example, the enterprise may have a single, centrally managed directory, and the purpose of the reference architecture is to give system architects a blueprint for how they use this in their projects.
A larger organization needs to be more flexible. Large organizations will rarely be in a position where there is a single portal or set of web servers running a single authentication and authorization server connecting to a centralized corporate directory. More likely, there will be hundreds of separate projects, each of which builds some new part of the identity infrastructure as it is deployed.
In this scenario, the reference architecture needs to be deeper and more flexible as well. For example, suppose that the interoperability framework allows three different authentication and authorization servers because of scale and legacy issues. The reference architecture would need to show how any of those three servers can be used with various web server and portal products as well as how they attach to various pieces of the enterprise-wide system, such as the corporate metadirectory.
Components of a Reference Architecture
A reference architecture has three primary pieces.
A statement of technical positions that guide system architects in making technical decisions.
An enterprise-wide consolidated infrastructure blueprint (CIB) that gives a blueprint for the overall digital identity infrastructure and shows how various enterprise components are hooked together.
Individual reference architectures for specific types of systems.
The next sections will describe each of these in turn.
Technical Position Statements
A clear statement of technical position on a variety of technology questions is a big help to system architects making individual technology and design decisions. In Chapter 14, we discussed the creation of statements about business principles as part of enumerating business drivers. Technical position statements build on those principles. We would expect principles to change infrequently and follow the business strategy of the organization. Technical position statements similarly flow from the technical strategy that the organization is pursuing.
Burton Group has developed a reference architecture for identity as part of its research and advisory services. They recommend organizations take a position on the following technology issues in identity management:
- Access management
How should an organization manage access to its applications and information resources?
- Directory access, administration, and security
How should organizations manage and secure their directory services while giving authorized applications, users, and administrators trouble-free access?
- Directory applications
What tools and interfaces should application developers use to tie applications to directory instances?
- Directory content, structure, and distribution
How should organizations organize, store, and reference information in a general-purpose directory system?
- Directory integration
How can an organization manage and share useful, high-quality data in multiple directory services, repositories, and other sources?
- Directory tiers, instances, and roles
How can organizations use tiered directory architectures to resolve structural, political, and functional differences that accompany general-purpose directory deployments?
- User management
How should an organization identify internal and external users, and manage the lifecycle of those users?
- User authentication
What strategies, technologies, and mechanisms should organizations use to authenticate users and provide appropriate protection to resources in a cost-effective, manageable manner?
- Public-key infrastructure
How should an organization plan and deploy tiered public-key infrastructure systems?
You may notice that some of the questions in this list look like the kinds of issues that you might take a stand on in your IF. Remember that the IF is the minimal ruleset and may not specify software and hardware choices in many instances. Technical position statements, on the other hand, are advisory and often give guidance beyond the requirements of the IF.
This list is not meant to be a complete look at every issue. As you build your IMA, you may find other technical issues on which you must take a stand to provide system architectures a firm foundation.
Making Decisions About Technical Positions
Identifying the questions, as we did previously, is one thing. Making decisions about the organization’s technical position is another. As CTO of a small startup, I took technical positions after a rather informal process of research and talking to some of engineers who worked for me. As CIO for Utah, we followed a more formal process. The end goal of the process was twofold:
Gather input from as many smart people as we could.
Create a group consensus around the decision.
In a large organization, the second point can be more important than the first. Taking technical positions does no good if people are going to question and even fight them.
Whether formal or not, taking a technical position requires several steps that can be enumerated and followed.
State the problem. The list of technology issues from the last section is a good starting point for problem statements. Usually the problem statements come down to a question that needs a technology answer such as “How will we use directories in our identity infrastructure?”
Determine your organization’s requirements with respect to the problem. The purpose of this step is to customize the problem stated in step 1 to the specific goals of the business. Rather than a simple list, this step can be best accomplished as a white paper that can be distributed and commented on.
List the options for solving the problem. This step enumerates the options at a high level. For example, in creating a technical position statement on directories, the options would probably come down to a large centralized directory, a metadirectory, or a virtual directory.
Research near-term future developments. This step protects you from any impending developments, and is a good point at which to check in with analysts and other outside sources about your plans.
Determine the evaluation criteria. One way to go about this is to prioritize the requirements determined in step 2 and assign point values for each.
Establish subordinate technical positions. Big technical position statements are often collections of related smaller technical positions. For example, in creating a technical position on directories, you might take technical positions about whether to rely on real-time integration or synchronization, how to create unique IDs, and whether to use packaged software or customize the integration between applications.
State positions and justify them with reasoned arguments. The final step is to state your positions. Usually, technical positions are dependent on assumptions and thus tend to be best expressed as nested IF-THEN-ELSE statements. The arguments can simply be paragraphs stating why certain choices follow from certain assumptions and are a reflection of the work in steps 1 through 6.
These steps can be followed informally by a small group or through a more rigorous process with larger groups. I’ve used offsite meetings and even professional facilitators. That may seem like overkill, but remember that your primary goal is to create consensus. Professional facilitators are trained to help groups do just that.
Consolidated Infrastructure Blueprint
The second component of your reference architecture is a consolidated infrastructure blueprint (CIB). A sample blueprint, courtesy of Burton Group, is shown in Figure 19-1.
The blueprint in Figure 19-1 is a general-purpose view of what a company’s identity infrastructure might look like. As you look at it, you should recognize many of the components and concepts we’ve discussed throughout the book.
There are two primary purposes for a consolidated infrastructure blueprint. The first is to show the actual components in your enterprise identity infrastructure and how they are connected to each other. To that end, the diagram shown in Figure 19-1 is only a starting point that must be customized to reflect reality in your organization. The general names given in the figure would be replaced by actual system and product names.
If your organization is like most, where identity infrastructure has been built in an ad hoc fashion over the years, the “as built” CIB may be quite messy and comprise multiple disconnected chunks. The “as built” CIB is used by system architects as they design their systems to determine how their system uses and connects to the enterprise identity infrastructure, and should thus be as accurate as possible.
Once you have an “as built” CIB, you can evaluate it against the maturity model that we introduced in Chapter 15. The CIB will show the state of identity storage, how authentication is done, and what infrastructure is in place to support authorization. Assign the CIB a maturity level. Don’t hesitate to assign different maturity levels to different aspects of the CIB. Share the evaluation widely and be prepared to adjust it as necessary based on the input of others. The idea is to end up with a consensus opinion of the maturity level, not just one person’s opinion.
Goal State CIBs
The second purpose of the CIB is to show goals states. In this use, the CIB shows how the infrastructure must evolve to meet organizational goals. Using the maturity evaluation as a starting point, determine what changes must be made to the CIB to advance the maturity of the infrastructure.
This kind of upgrade doesn’t happen as a single monolithic project, so infrastructure planners should create a series of “goal state” CIBs showing the roadmap that they envision for the infrastructure build-out. This roadmap is also useful to system architects as they make their plans so that they can design systems with the future in mind.
CIBs should be accompanied by documentation that describes in as much detail as necessary the information in the blueprint. This is the place to document requirements, reference policy, and point system architects to other detailed information.
System Reference Architectures
In a large organization, using a single enterprise-wide identity infrastructure is often impossible for geographic, political, or technical reasons. For example, Utah runs hundreds of web servers. My goal as CIO was not to have everyone use a single enterprise infrastructure for web servers or even to use a single authentication and authorization component. Rather, we had to find ways for individual projects to build portions of the identity infrastructure and yet have them work in an interoperable fashion.
We’ve seen the role that policies and interoperability frameworks (IF) play in making this possible. The consolidated infrastructure blueprint that we saw in the last section also plays an important role. In addition to those important aids, we can give system architects a head start when they design a system by creating system reference architectures (SRAs) that show how an individual system can be put together from components in the IF so as to work with the CIB. The system architect can customize the SRA to the specific job at hand rather than starting from scratch.
As an example, suppose your enterprise infrastructure used a metadirectory to consolidate directory information and that you had also deployed a policy server and provisioning server from a particular vendor in accordance with your interoperability framework. A new project to build a partner portal has been launched. The project is of sufficient scope that it will need its own web servers, and the identity data will be stored on a local directory for business reasons unimportant to our discussion.
Figure 19-2 shows an architecture diagram for an SRA for web server authentication and authorization that the project might use as they make decisions about the platform. This diagram is much simplified, but gives the idea. The IF tells the project the recommended identity server and directory software to buy. Further, it gives information about how the identity server and directory need to interface with enterprise resources. Documentation with the SRA would give detailed information as well as point to other reference material. In an ideal situation, the project would know that these components had been tested together and that the recommendations were based on the experience of the organization and others in similar situations.
Conclusion
Reference architectures are not intended to be straightjackets that restrict project choices, but reference material that system architects can use to get a head start on designing platforms to meet the needs of the business. A good reference architecture tells the system architect what technical choices the enterprise has made and how to build projects that are interoperable with the overall enterprise infrastructure. Good reference material helps projects succeed in interoperating with other systems and also saves the enterprise money by saving the project time in researching options and developing solutions.