September 2009 - Posts

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 ?.

Posted by cibrax | 4 comment(s)
Filed under: , ,

As Dr Nick announced in this post, WCF 4.0 will ship with a new feature to configure a client channel from a configuration source other than the traditional section in the application configuration file (I discussed a workaround for doing the same thing in WCF 3.0 a time ago in this post)

This will provide the flexibility to deploy some binaries with the client proxies together with an independent configuration file (which might be a resource file, a stand alone file included with your application or something you can download from an specific place), so the main configuration file does not need to be touched at all.

A new channel factory “ConfigurationChannelFactory” is included as part of the System.ServiceModel.Configuration namespace to create channels from an alternative configuration source.

var fileMap = new ExeConfigurationFileMap();
            fileMap.ExeConfigFilename = "otherFile.config";

var configuration = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);

var factory = new ConfigurationChannelFactory<IService1>("BasicHttpBinding_IService1", configuration, new EndpointAddress("http://localhost:49187/Service1.svc"));

var client = factory.CreateChannel();

var s = client.GetData(3);

Console.WriteLine(s);

The file “otherFile.config” is just a simple configuration file that contains the client definition and configuration for using the “IService1” service.

<configuration>
 
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
              <binding name="BasicHttpBinding_IService1" >
                    <security mode="None">
                    </security>
                </binding>
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:49187/Service1.svc" binding="basicHttpBinding"
                bindingConfiguration="BasicHttpBinding_IService1" contract="ServiceReference1.IService1"
                name="BasicHttpBinding_IService1" />
        </client>
    </system.serviceModel>
</configuration>

All this code is based on the .NET 4.0 beta 1, so it might change in the final release.

Posted by cibrax | 2 comment(s)
Filed under: ,
More Posts