Chapter 17. Interoperability Frameworks for Identity
Interoperability frameworks (IF) are nothing more than listings of accepted standards, both external and internal, that an organization uses. An IF is an essential prerequisite to enabling decentralized identity infrastructures that nonetheless work together to achieve the organization’s goals and objectives. A good IF complements policies and provides a foundation on which they can be more effectively created and enforced.
An IF is created in accordance with the same governance procedures that were discussed in Chapter 14. This chapter will discuss the properties and content of a good interoperability framework.
Principles of a Good IF
An interoperability framework is a working document that systems architects, software developers, and others can use to guide their work. There are several significant principles that a good IF should follow.
- Derived from current practice
A good IF is never created in a vacuum. Your organization is using particular standards and technology right now, and that’s what you should start with when developing your IF. Even though the first draft may begin as a ragtag collection of disconnected and conflicting standards, over time, the list can be refined and pruned. We’ll see later in this chapter how to use status designations in the IF to accomplish this goal.
- Enforced
A good IF will guide the engineering of the identity infrastructure. Just as with policy, this goal is achieved only if the organization is willing to enforce the IF. As with any standard or policy, a process should be put in place for exceptions and approving deviations from the IF. Nevertheless, adherence to the IF should be expected within the organization, and the governing organization must have ways of bringing projects into compliance.
One way to do that is by controlling purchasing. The IF should guide purchasing decisions. In a large organization, this might be enforced through the purchasing department. Even in smaller organization, procedures can usually be put in place to reinforce the IF. For example, in a small organization, a single person typically has final signature authority on hardware and software purchases and thus can guide the infrastructure toward certain standards .
- Understandable
Technical and business management must understand the IF. Most important is that management understands the need for standards and why certain standards have been placed on the list and others have been left off. If management does not understand the motivation behind choices in the IF, you will have a tough time getting cooperative compliance.
- Complete
The IF should take into account the full context of the organization. When you create the IF, include every standard currently used by the organization. Make sure to review those and identify any gaps where there is no standard, de facto or otherwise.
- Flexible
Ensure that the IF is subject to a governance process that can rapidly adapt or respond to changing business needs. The idea is not to create a straightjacket that keeps the organization from doing anything, but to channel activity into paths that lead to the interoperability of decentralized systems.
Contents of an Identity IF
As shown in Figure 17-1, an IF contains three primary kinds of standards:
- External standards
Examples might be the kinds of XML standards, such as SAML, that we discussed in Chapter 11.
- Software standards
These are software choices that the organization has made. An example might be a decision to support MySQL or Linux.
- Hardware standards
These are specific hardware choices that affect interoperability. The organization may set some hardware standards strictly as a purchasing decision. Those would not typically be included in the IF. Inclusion in the IF should be done on the basis of interoperability benefits rather than purchasing power or efficiency.
Each of these may be broken into subareas, as necessary, and in each subarea choices are enumerated and documented. In addition to sections enumerating standards, an introductory section should contain the following information:
- Guidelines for use
This section describes how the document is to be used.
- Governance
This section describes the governance procedure that created the IF and how the IF can be changed. This section also describes the review cycle for the overall document.
- Application
This section describes the scope of the IF and where it should be applied.
- Exemptions
This section enumerates any global exemptions and provisions for requesting exemptions.
Standard Status
Each standard in the document will have a status that indicates whether following the standard is mandatory or not. There can be any number of status levels depending on the needs of the organization. The following are adapted from the status levels that we used in the State of Utah to define an IF:
- Approved
An approved standard is critical to the enterprise and will be enforced.
- De facto
A de facto standard identifies choices that are widely accepted because of widespread use within the enterprise and industry.
- Emerging
Emerging standards may have future value within the enterprise but have proven no specific benefit at this time. The enterprise may be conducting a pilot project to establish the potential benefits and risks of selecting this standard.
- Sustained
A sustained standard indicates a standard or practice that no longer shows promise but is still used or even expanded because of a prior standards solution.
- Sunset
A sunset designation is given to a standard or practice that has been abandoned for a better solution. It is not a favored standard yet continues to be in use in the enterprise. Projects should plan to migrate away from solutions assigned this designation as soon as practical.
- In process
An in process designation refers to a standard that is going through the governance process and awaiting approval and an assignment of status.
Approved and de facto standards represent areas where there is significant technical or monetary investment. Approved standards are the most powerful designation for creating standard environments and conventions to promote interoperability.
Sustained and sunset standards are generally nearing the end of a lifecycle and should be avoided for new development without extenuating circumstances. There will always be legacy standards in the organization. Those that the IMA intends to support should be designated as sustained. One goal of the IF is to ensure that standards don’t outlive their useful period and are retired when convenient for the organization. The sunset designation is the architect’s tool for moving the organization away from standards that are no longer serving a purpose and should no longer be used.
Emerging standards show promise and are likely to become approved standards after they have proven themselves in a pilot project or other demonstration. The emerging designation is the architect’s tool for calling attention to new standards and encouraging their use.
Listing Standards
For each standard, the IF should list the following information:
- Description
The description might be as simple as the name of the standard if sufficiently descriptive.
- Reference
This would typically be a URL pointing to the location of the standard. For internal standards, the reference could be a URL for the document or other internal ID.
- Status
This would give the status of the standard as discussed above.
- Review cycle
This notes the recommended review schedule (e.g., annually, biannually, etc.)
- Notes
This is the place to list any additional information. Use this section to describe motivation or refer to a larger document that does so. This is also where conditions for use or exceptions can be noted.
Example Interoperability Framework
An entire IF can take several dozen pages. Table 17-1 shows four entries from an interoperability framework. The example shows parts of two subareas: Encryption Standards and Federation Standards. These would be a larger table of external standards that the organization supports.
|
2.3 Encryption Standards | ||||
|
Description |
Reference |
Status |
Review |
Notes |
|
XMLsig |
Approved |
Annually |
XML Signature Syntax and Processing (XMLsig) is defined by W3C. W3C Recommendation 12.02.2002. | |
|
XMLenc |
Approved |
Annually |
XML-Encryption Syntax and Processing. W3C Recommendation 10.12.2002. XML Encryption is used to secure encrypted transport of content. Used when security on the transport-level (such as SSL) is not sufficient. | |
|
2.4 Federation Standards | ||||
|
SAML (Security Assertions Markup Language) Version 1.1 |
http://www.oasis-open.org/committees/download.php/6837/sstc-saml-tech-overview-1.1-cd.pdf |
Approved |
Annually |
OASIS/SSTC Version 1.1 - 22.09.2003. SAML enables single sign-on and enables federated identification mechanisms. |
|
SAML (Security Assertions Markup Language) Version 2.0 |
http://www.oasis-open.org/committees/download.php/7874/sstc-saml-tech-overview-2.0-draft-01.pdf |
Emerging |
Quarterly |
SAML 2.0 is currently a draft specification. Use in production project is subject to approval and supporting product availability. |
Notice that the emerging SAML 2.0 standard is reviewed more frequently and that its use is made subject to approval by the notes. These reviews need not be lengthy or subject to the formal governance process unless something like the status is going to change.
The document shown here is formatted as a table. This is a common way to format an IF, but you can see that it suffers from some limitations because there is insufficient space to include many details. Also, simply publishing the IF as a paper document, or an Excel spreadsheet on the Web, limits its usefulness. A large IF should be put into a content management system and made available over the Web in a variety of formats, including a table-based summary for quick browsing with links to detail pages for each standard. These detail pages should contain all of the information shown in Table 17-1 along with other useful information such as supporting standards, the relationship of the standard to others, projects inside the organization that employ the standard, links to procurement information, and the contact information for subject-matter experts.
One good example of an online interoperability framework is the Danish government’s Reference Profile.[*] Like any good IF, this online resource gives members of the Danish government’s IT community useful information on what standards are supported and how to find out more information about them. In addition, the online application allows the IF to be searched and for each individual standard, users can retrieve a detail page, link to the standard’s official reference document, save the standard in a bookmark, or write a review.
A Word of Warning
One of the real dangers of creating an interoperability framework is the temptation to be overly restrictive. Many IT managers have made the mistake of trying to home in on single technology choice on the premise that such standardization will lead to better efficiency within their organizations. In theory this is true, but in my experience, it’s a rare organization that has the discipline to pull it off. Perhaps, more importantly, such single-minded devotion to specific technologies can limit agility and create an organization that is overly rigid.
As an example, most large organizations are going to be running a mixture of Linux and Windows (at least on their servers) and developing in multiple programming languages. I found as CIO for Utah that it often made real sense (and cents) to have one project using IBM’s WebSphere J2EE application server, another using BEA’s WebLogic, and yet another using the jBoss open source application server. You’d think that because all of these projects were based on the same standard (J2EE, in this case), they’d be able to use the same application server, but it just didn’t bear up under analysis.
Here’s one real scenario where that happened. We went out to bid on a $30 million project to build an eligibility determination system for welfare benefits in the state. The project would replace a 20-year-old green screen COBOL application. The winning bidder happened to be IBM. If we’d put in the Request for Proposals that the system had to use WebLogic, which many projects in the state were using at the time, IBM would not have bid and the state would have lost out on what was ultimately the best system as judged by business and technical people working on the bid.
You might conclude that it’s hopeless, but I don’t think so. You’ll get more interoperability mileage by picking standards to support in the IF than by picking identical software and hardware or software development environments. If the software and hardware support the standards that are important to you, then you’ll get interoperability anyway and still be able to reap the benefit of picking hardware or software for other reasons such as price or feature set. TCP/IP is a real example of this principle in action. This networking standard is now so pervasive that we wouldn’t even think of purchasing certain hardware or software that couldn’t internetwork according to the TCP/IP standard. Choosing standards within your organization can provide the same benefit in other areas.
Conclusion
An interoperability framework for your IMA is a crucial foundational document that should be created as one of the first deliverables of an IMA effort. Policies and other documents should reference the IF rather than calling out specific products and standards by name to ensure that they are modular and easy to update. Creating an IF needn’t be a difficult task. The document is relatively straightforward, and you can probably gather currently used standards from your organization easily. The hardest part is likely to be the assignment of status levels to various standards, particularly those of approved and sunset, because they call for action on the part of system architects and implementers.