Identity management requires card smarts

Many of the components required to meet Homeland Security Presidential Directive (HSPD) 12, which mandates a standard way of identifying federal employees and contractors, have been around for a while and are well-understood.

For years, some agencies have been using the card management, printing and registration systems needed to supply smart cards. The National Institute of Standards and Technology has been compiling specifications for the cards’ functions, interface technologies and biometric identification data.

On the other hand, the requirements for identity management systems (IDMS) are not as far along. Agencies must deploy such systems to handle ID card distribution, apply biometric data to the cards and manage the databases that contain identity information.

In addition, an effective IDMS must enable a single card to grant access to physical buildings and information technology networks — two worlds that traditionally have used separate systems and operated in different security domains.

Because an IDMS must support many tasks and adapt to many environments, a specific description is nearly impossible to devise. Agencies must resolve this issue, among others, as they try to meet the October deadline for issuing smart cards to employees.

An IDMS “is more of a concept than any particular thing,” said David Temoshok, director of identity policy and management at the General Services Administration. “There are no standards you can set for [an] IDMS. There is no single approach to implementing one.”

In a December 2005 request for information for a future HSPD-12 contract, GSA defined an IDMS as the secured database that holds all applicant identity records.

More specifically, an IDMS should:

• Perform the verification and validation functions required to confirm someone’s identity.


• Hold and process applicant status information.


• Ensure that a card applicant has met all requirements before receiving a card.

For agencies, a complete IDMS construction can be a long, complex and costly project, experts say.

“There’s going to be a lot of integration points between an IDMS ‘blob’ and other systems in the environment,” said John Gist, a program manager at Northrop Grumman IT. “Unfortunately, there is no easy answer.”

Agencies possess a number of databases, such as those managed by the human resources department, that already include much of the identity information necessary for a system that complies with HSPD-12.

The IDMS then becomes the integration glue that links all of those databases and handles the identity data from a central location.

But there’s no one way to consolidate it all, said Idan Shoham, chief technology officer at M-Tech IT, an identity management software vendor.

Seemingly, the simplest approach is to base the consolidation on human resources databases and use that data in other identity-driven applications, such as network directories and electronic messaging systems.

“However, that only goes so far,” Shoham said. “The HR system wouldn’t necessarily know anything about contractors, for example, and there would be an assumption that the HR database is accurate, current and fine-grained. But most often, that’s not true.” In that case, he said, the IDMS would need more information than the human resources database could provide.

Keep it simple
Some experts warn that the concept of an IDMS is becoming too complicated and all-encompassing, which could inhibit how people tackle implementation. Anteon, a systems integrator, seeks to simplify ID cards and focus on their uses, said Scott Price, vice president of the company’s systems integration group. For example, first responders’ primary need might be to know who must get in and out of a particular building or area during an emergency.

Price said that an IDMS must facilitate real-time changes in privilege levels.

“The important thing is to know whether or not a person works at a certain place, where they will work tomorrow, can they do certain things in a crisis and so on,” Price said. “Quick transfer of privileges is also important for interoperability,” so an employee of one agency can gain access to another agency’s building with the same card.

John Wall, principal technology specialist at Microsoft Federal, said the key to any IDMS is how well it handles exception processing.

“What happens when someone leaves a card at home or loses it?” he asked. “Does that person get a replacement? After a certain time is that card revoked? How do you reset identities in this case?”

That knowledge is also important when using one card for both physical and network access, he said, adding that the challenge in those circumstances is knowing whether the card is valid.

Some experts say the trick to building an IDMS that complies with HSPD-12 is to focus only on the directive’s needs rather than attempting to deploy a full IDMS implementation.

HSPD-12 doesn’t explicitly call for an IDMS installation, but the requirements would be hard to satisfy without one, Shoham said.

“However, an enterprise IDMS takes money and time to set up, anything from 12 to 18 months, and that’s fast,” he said. “Clearly, this is something you have to do incrementally.”