Sxip simplifies identity management

15.05.2006
Most enterprises have worked hard to properly authenticate users and manage access to systems. But as more enterprises subscribe to SaaS (software as a service) offerings or other provisioned services, managing identities and access privileges gets harder. How does your provider know how to authenticate users? And can providers and enterprises afford to support a web of identity management systems among them?

How do you reconcile user identities across organizational boundaries? Sxip wants you to use its appliance

Most enterprises have worked hard to properly authenticate users and manage access to systems. But as more enterprises subscribe to SaaS (software as a service) offerings or other provisioned services, managing identities and access privileges gets harder. How does your provider know how to authenticate users? And can providers and enterprises afford to support a web of identity management systems among them?

Sxip Identity's answer to these questions is the Sxip Access appliance. IT maintains its existing identity management system, using its preferred authentication method. The service provider passes user authentication data along to the enterprise. The Sxip appliance handles the interactions between the two systems, so no custom integration is required, says Dick Hardt, Sxip's CEO. "This lets ASPs accept a wide variety of credentials without having to do something special for each," he says. IT can use the same appliance to receive authentication requests from multiple providers.

But Hardt sees Sxip Access as just the first step. Sxip Access still requires a tight coupling between provider and enterprise -- they need to have an existing relationship and agree on what data will be passed on to the enterprise, even if the enterprise does all the validation work.

So Sxip is working on Version 2 of its Simple Extensible Identity Protocol for an approach to identity management that eliminates the need to exchange mutual secrets (passwords, biometrics, secret questions, and other tokens), the standard authentication approach today. Instead, the user authenticates himself to the validation engine of his choice (internal IT or a service provider) and transmits an encrypted identifier message to the other party, which then uses its choice of provider to verify the integrity of the message. If the message is valid, the recipient has the identifier and associated profile to know what permissions to provide. This is similar to the approach used in Kerberos and SAML, he notes, but is better suited for loose federations of interactions.