Scenarios for WS-Passive and OpenID

I was wondering these days what would be the point in using WS-Passive when there is another simple sign-on solution, OpenID, that works really well and it’s getting a great adoption in the community. I can not say the same about WS-Passive, I haven’t seen any concrete implementation yet (For instance, Microsoft is planning to release a first implementation as part of the WIF framework before the end of this year).

However, I reached the conclusion that both technologies are prepared for addressing different scenarios. For me, OpenID is more suitable for community or social networking web sites that expect to have a great number of users, and can benefit from using the large user databases that some of the existing OpenID providers already have. This is also a great thing for the final user as he can reuse his public OpenID identifier to log into all these web sites. 

On the other hand, WS-Passive seems to work better for enterprise scenarios in companies that might have some sort of security infrastructure in place (Customer user databases, active directory, active STSs for services) and do not want to have third parties (other than the parties involved in the business) to participate in the business transactions or to share their user databases with these parties. This is closely related to one of the identity laws that Kim Cameron announced a time ago. Law #3, “Justifiable Parties”, Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.

This was one of the big failures in the adoption of Passport as Single-Sign-On technology. Some relying parties did not understand the purpose of having Microsoft (and Passport) involved in their business transactions.

In addition, WS-Passive only specifies a way to interchange a security token with user claims between the involved parties (Client, STS and Relying Party), so it provides the flexibility of using any security token profile. The most common token profile used today is SAML, as it can be customized with custom assertions or claims specific to the business. OpenID also specifies a way to exchange custom data (other than Simple Registration or SReg data) through the “Attribute Exchange” spec. However, it looks like many of the existing relying parties or identity providers do not support this spec as it is discussed here.

I am just guessing :). What do you think ?.

4 Comments

  • What is WS-Passive? Do you mean WS-Federation? If so, there are lots of implementation of that standard:
     
    * CA Federation Manager
    * HP Select Federation
    * BMC Identity Federation Manager
    * Oracle Identity Federation
    * Novell Access Manager
    * Ping Identity PingFederate
    * Centrify DirectControl
    * Quest Single Sign-on for Java
    * Symlabs Federated Identity Suite
    * Microsoft ADFS (v. 1 and the forthcoming v. 2, PKA Geneva Server)

    If you're implementing a passive STS (an IdP w/ an STS that implements WS-Federation), you can allow the user to authenticate via OpenID. So, I see these two standards as complementary not mutually exclusive.

  • I am talking about WS-Trust Passive Profile, which is what Geneva Framework implements in the passive STS. Are you sure that all those products implement this spec ?. I know Microsoft ADFS does, but the development story seems to be much better in Geneva Server.

    Yes, they are complementary, but I not see the real point in using them together.

  • With OpenId, you can make it so that you only allow a specific (may be company-owned) provider and don't allow the user to choose which OpenId url to hit, but time and again and the lack of examples still make me stay with WS-* stack. I just feel like everything is possible with OpenId/oAuth but the lack of examples (unlike Geneva) is a killer. Can't compare apples to apples with Geneva due to lack of examples for enterprises to look through. Had a few discussions on the DotNetOpenAuth forums but not a single example of multi-site/service SSO.

  • Just to add, I don't see why you'd want to use them together unless your enterprise wants to allow OpenId from an external provider. In my enterprise, I would never want to allow some external OpenID provider. Use one or the other and trust a specific STS/OpenId provider. Just don't see it within the enterprise.

Comments have been disabled for this content.