HP takes swipe at Sun/Microsoft SSO proposals

1 minute read

I’m a little disappointed to read this article quoting Sai Allavarpu, HP’s director of product management and marketing for security and identity. The article says

According to Sai Allavarpu, […] despite the labeling and promotion, the specs do not promote interoperability at all.

This is pretty disingenuous stuff. Yes, several vendors support multiple protocols, but, and this is the important bit, without this effort, Microsoft would likely have brought Longhorn to market supporting only WS-Federation. Clearly these specifications promote interoperability between Microsoft and the rest of the identity management industry.
Yes, it is possible to support multiple protocols at the identity provider without these new protocols, and Sun’s Access Manager does just that with its support for multiple versions of Liberty ID-FF and SAML, but the “negotiation” specs, as Sai terms them, do have real value in a world where federation standards are evolving and identity and service providers will change their sets of supported protocols over time.
It’s a mistake to see these two specifications as the end of Sun’s interoperability efforts with Microsoft. To quote one of the greatest Britons of all time: “This is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning.”

Updated:

Comments

Rohan Pinto

I agree Pat,<p>But what makes me wonder is that Sai, Paul, Arlene to name a few who currently <em>“kinda”</em> power up HP’s Identity, Security and Portal Server practices are extremely familiar names around here… ;-) <em>winks-2-da-nth-power</em>

ALSO: HP seems to be investing a lot in building portal server and identity server products, but however they are engaging external mediocre skillsets from low cost consulting firms to develop these products.. <em>Makes me wonder why ?</em>

Hubert Le Van Gong

Being one of the author of the specs I can say one of the problem with this article is that it does not sufficiently separates the protocol itself (WSSOMEX) from the profile.
I would tend to agree that a profile that mandates both protocol suites does not do a supremely efficient job but would argue that to start interoperating ones need to understand each other (i.e. finding a common language): this is exactly what the WSSOMEX protocol proposes.

Cheers,
Hubert

Leave a Comment

Your email address will not be published. Required fields are marked *

Loading...