Who, what, where

WITH THE PROLIFERATION of Web-based applications, extranets, self-service portals, and heterogeneous enterprise systems, the development of automated identity management and provisioning systems is becoming a high priority. Almost everything’s an identity-based service these days, so creating, modifying, managing, and terminating identity-based access to multiple systems — for multitudes of employees, customers, and business partners — has become an overwhelming task.

Vendors who started by attacking one piece of this puzzle, such as Web single sign-on, are scrambling to assemble end-to-end solutions, including fully automated, workflow-driven, federated systems for identity creation and management, authorization, authentication, and auditing. Along the way, they’re facing some thorny technological issues, including integration, architecture, and security challenges, not to mention a morass of competing standards.

Directories and systems integration

Identity management and provisioning would be less of a headache if the existing user-information repositories were all directory-based. Although increasing amounts of user data, on which authentications and authorizations are based, are stored in LDAP-type directories, most source systems are nonstandard and inaccessible without custom-built connectors.

This makes building scalable, ID-based provisioning systems a challenge. “Do you have support for legacy system number 55 running on some particular form of AIX?” asks Nand Mulchandani, CTO of Oblix in Cupertino, Calif. “ID management is fundamentally about integrating heterogeneous systems together.”

Furthermore, fully automated provisioning requires not just messaging-level integration, but two-way integration with the specific security environments and protocols used by the target systems. This requires translators or metadirectories to enable the master provisioning system to do what a local administrator could do locally, including managing authorizations and passwords.

Architecture and security

“Metadirectories and provisioning are on a collision course,” explains Deepak Tenaja, CTO of Netegrity, headquartered in Waltham, Mass.

Robust, scalable provisioning metadirectories are necessary, he claims, to enable bidirectional synchronization of user attribute data. Two-way systems are required so authorization status changes in a local system can be synchronized between the local and the master system, not just pushed out one-way. And they must work across both extranets and internal applications. Given the amount of custom integration work required, today’s metadirectories are really more toolkit than application.

Another challenge for identity management providers is how to architect their systems: as a network of distributed software agents that live on target systems, or with more intelligence centrally located. The distributed approach feeds identity data and changes from the targets into a central store or database for rationalization. The centralized model operates more like a Google for identity — a pointer system or virtual metadirectory that performs auto discovery and mapping (for password synchronization, for example), as well as real-time management, analysis, and rationalization.

Both approaches have their advocates. “The agent-proliferation problem becomes a nightmare” with large numbers of host systems, and makes it slower to integrate with legacy or homegrown end-points, claims Mark McClain, president of Austin, Texas-based Waveset, which uses the centralized approach. Jeff Curie, director of product management at Access360, which uses agents, disagrees. “They can deploy in a week, [while] it might take us a week and a half. … But you’re buying this product for 10 years,” he asserts. More vendors are starting to offer both options — combined local and remote control over managed identity and provisioning environments.

Workflow, delegation, and audit

Then there’s the security challenge. To hackers, ID management and provisioning systems are like a master key to a hotel, a juicy target. With the current emphasis on cost-effective self-service (such as password reset), there are very few humans guarding the key box. This places a premium on making sure no one can spoof or hack the provisioning system itself.

That’s where encryption and secure networking (SSL for Web and Triple DES for non-Web), coupled with PKI certificates for authentication, come in.

“With the things that we’re creating, like rights of system administrators, it really becomes a distributed computing problem,” says Access 360’s Curie. “If we can successfully lock down the accounts in an environment, then what a hacker will go after is the provisioning system itself, so he can get those accounts back.”

Another set of challenges involves the complexity of incorporating process and business rules, such as workflow, into identity management and provisioning. This means creating robust workflow and policy engines that can embody and enforce complex rules to govern which managers must sign off on a new hire’s authorizations, which participating systems are authoritative in case of conflicts, and so on. “Basically what we’re talking about is how do you codify security policy?” Waveset’s McClain says.

Furthermore, these systems must support so-called “delegated” policy — a vendor being able to provision a subcontractor with certain rights on his customer’s system, for example — often across as many as five or six layers of supply-chain participants. This requires an abstracted management model for administrators, and a group management capability to assign rights based on attributes.

In some cases, for reasons of privacy or local control, an enterprise may even want to install multiple provisioning systems operating under a single master set of policies, with unified audit trails or risk-analysis reports pulled from multiple instances. This invariably leads to issues such as which is the master system and which is the servant, the hierarchy of the systems determining which direction the policies flow.

Liberty vs. Microsoft

Several standards efforts are underway to help make identity management and provisioning across diverse systems more straightforward. SPML (Service Provisioning Markup Language) is a proposed XML standard for provisioning (creating, modifying, and deleting accounts) across systems. SAML (Security Assertion Markup Language) is a session-level request-response model for exchanging security assertions (authentications and authorizations) across corporate boundaries with other trusted security engines.

In the J2EE world, Java Specification Request 115 is a proposal for how J2EE containers would support authorization and integrate with security engines, although vendors of those engines claim that the application server vendors don’t really want to play ball with them. On the Web services front, Microsoft, Verisign, and IBM have introduced WS-Security, and have accepted the use of SAML within WS-security envelopes. An OASIS committee is trying to extend WSDL to include information about users and roles, which could help manage and federate identity across portals. And so it goes.

Then there’s Microsoft’s .Net/Passport and the Liberty Alliance. Originally conceived as a consumer authentication system (as opposed to enterprise authorization), both architectures are supposedly moving toward a federated model that will facilitate identity management, if not provisioning, across extended enterprises.

The Liberty Alliance has published its phase one specifications, heavily based on SAML (Security Assertion Markup Language), which allow multiple operators to operate federated Passport-like services, cooperating with each other to allow cross-system authentication. For its phase two, Liberty is looking to create a higher-level framework that goes beyond SAML to define how security policies can be expressed between companies, how trust relationships can be established. “It will be very hard to standardize some of those things,” says Tenaja.

In the meantime, Microsoft, which has been operating its Passport system as a prototype for its .Net authentication architecture, has yet to define how its technology, fundamentally based on Kerberos and built into Windows and .Net server, will interoperate with either SAML or Liberty. “I think it’s gonna be a little tough” says Oblix CTO Mulchandani. “There’s no representation for a Kerberos ticket in XML today.” So how will Liberty and .Net/Passport get integrated into the emerging enterprise identity and provisioning architectures? It’s anyone’s guess right now.

In the future, enterprises may deploy interoperable, standards-based, fully automated end-to-end identity management and provisioning systems or best-of-breed building blocks to create those systems. But for now, don’t be surprised if you end up talking to a help desk to get a new password or waiting to get account access for some paperwork that’s sitting on a sys admin’s desk somewhere.

Source: www.infoworld.com