An ID for all domains

A police officer finds an elderly man unconscious. The officer uses the man’s identification to locate his medical history and learns that the man has diabetes. The officer also scans a human services database and learns that the man is in social services custody because he can’t care for himself. Finally, veterans records reveal the treatment the man has been receiving at his local Veterans Affairs Department hospital. Based on all that information, the officer can ensure that the man gets the proper medical care, that his social services caseworker is notified and that his treatment is coordinated with VA physicians.

In a perfect world, government workers would have access to all the resources and data they need to do their jobs. It wouldn’t matter whether other agencies held the data or applications ran on different networks. The information technology systems would take care of those details and allow workers to access appropriate resources.

The idea behind cross-domain identity management is to give people in different domains, such as different agencies, appropriate access to data and applications based on their identity.

In nondigital environments, that sort of exchange happens all the time. For example, each state issues driver’s licenses, but every state recognizes other states’ licenses.

When it comes to computer networks, cross-domain identity management is extremely complicated, for several reasons. First, an employee might be authenticated at agency A but not at the level of authentication required by agency B.

“Trust is not transitive,” said John Chirapurath, director of marketing at Microsoft’s Identity and Security Division. “If A trusts B, and B trusts C, A may or may not trust C.”

Second, even if a person’s authentication level is sufficient, that information must be transmitted to agency B, so the employee still might not be able to automatically access the information he or she needs.

Finally, any changes in an employee’s status — for example, taking on a new position or leaving the government — must somehow ripple through all the agencies immediately.

Although cross-domain identity management is difficult to implement, it has many advantages, especially for government agencies. If a single credentialing process is sufficient to satisfy many agencies, the entire government saves money by not performing credentialing for every agency.

“The resource owner need not manage access to that resource,” said Jackson Shaw, senior director of product management at Quest Software, a vendor of identity management applications.

Furthermore, employees can access information and resources more simply and quickly. For example, the Army has 14 domains, and lowering the barriers among them would have tremendous value.

Finally, people receive better services when government employees can do their jobs efficiently.

Political hurdles

Cross-domain identity management faces legal and political challenges in addition to technological ones. Suppose someone misuses access to order 10,000 unneeded widgets. Who is legally liable for that mistake: the user’s agency, the agency with the order application or the agency that allowed the access?

Political and legal issues also include concerns about privacy and security. “Each organization’s security needs are different, but a common thread across global governments is a strong need to enable more sharing of information without compromising security,” said Frank Mayer, president, chief technology officer and co-founder of Tresys Technology.

The banking industry has done a lot to enable cross-domain identity management on an everyday level. For example, customers of one bank can perform certain transactions at another. The federal government is another pioneer in this area, and several federal projects are exploring solutions to cross-domain identity management.

• The Federal Bridge Certification Authority is a nonhierarchical authority for public-key infrastructures. Agencies can use FBCA to authenticate credentials issued by other agencies. It uses a federated approach in which identities are managed using trusted relationships defined and shared among participants. FBCA also enables links between government agencies and outside organizations, such as vendors.
• Homeland Security Presidential Directive 12 specifies personal identity verification standards for people who access government facilities and systems. The goal of HSPD-12 is to allow credentials to work across agency boundaries. Many agencies are using smart cards to implement HSPD-12 standards. For instance, the Defense Cross-Credentialing Identification System is a secure, federated credentialing system that enables the Defense Department and contractors to comply with HSPD-12. However, full interoperability among agencies is still a long way off.
• E-Verify is an online identity verification system run by the Homeland Security Department and the Social Security Administration. Employers can check the work status of employees against more than 400 million SSA records and 60 million DHS records. More than 80,000 employers participate.

Cross purposes

Because cross-domain identity management is complicated, you probably need a compelling reason to implement it. Before rushing to set it up, examine how cross-domain identity management will help your agency function more productively or efficiently.

Also, try to identify other agencies that might already have some components in place and partner with them. Although all agencies must implement HSPD-12, they’re at different stages of the process.

And bear in mind that any durable cross-domain identity management system should be vendor-neutral. “As long as you can transfer the information in a format everyone can understand, the back end doesn’t matter,” said Sachin Nayyar, chief identity strategist at Sun Microsystems.

Several organizations — such as the Liberty Alliance, an industry group dedicated to developing open standards and best practices for identity management, and the Organization for the Advancement of Structured Information Standards (OASIS) — are working to establish standards to make such data transfers easier.

Using physical tokens, such as smart cards, can simplify authentication, but you still need to anchor those cards to identity information on the back end and enable authorization across domains.

Cross training

Even if you implement cross-domain identity management, your challenges aren’t over. Your applications also must support federated identities. You should investigate whether your vendors provide versions of their software that will accept those identities. Otherwise, you’ll need a proxy that handles the identity management, such as Microsoft’s Intelligent Application Gateway.

You also might need to use a trusted operating system to support cross-domain solutions, such as Sun’s Trusted Solaris or Red Hat Enterprise Linux 5 from IBM and Red Hat. If your agency's applications handle classified data, a trusted operating system can provide the foundation necessary for secure processing.

It’s important and often simpler to take advantage of existing technology. For example, Quest Software’s Vintela Single Sign-on for Java performs authentication using Microsoft’s Active Directory, which many agencies and other organizations already use. “Users log on to Active Directory every day,” Shaw said.

Defining the criteria for different levels of access is crucial. “Working out the business procedures is 90 percent of the problem,” said Roger Sullivan, president of the Liberty Alliance Management Board. You need to define what you’re trying to do, what you want to allow and how you make those decisions.

Agencies should take advantage of the information available from standards groups such as the Liberty Alliance and OASIS. Their member lists can point you to potential vendors and other agencies, and their online resources can help you educate your employees and plan projects.