Clarity, Technology, and Solving Problems | PracticeThis.com
WP7 App with Key Windows Azure resources – Slides, Videos, How-To’s, and T-shooting – for quick consumption on the go.
This post is based on WIF Built-in Bindings Overview and AD FS Endpoints. This information should provide a more cohesive view for developers when developing claims aware WCF services using AD FS and WIF.
There are 30 scenarios here. Working on guidance when to use what.
AD FS Endpoint
UserNameWSTrustBinding userNameTrust13MixedBinding = new UserNameWSTrustBinding(SecurityMode.TransportWithMessageCredential);
UserNameWSTrustBinding userNameTrust13TransportBasicBinding = new UserNameWSTrustBinding(SecurityMode.Transport, HttpClientCredentialType.Basic);
UserNameWSTrustBinding userNameTrust13TransportDigestBinding = new UserNameWSTrustBinding(SecurityMode.Transport, HttpClientCredentialType.Digest);
KerberosWSTrustBinding kerberosTrust13MixedBinding = new KerberosWSTrustBinding(SecurityMode.TransportWithMessageCredential);
IssuedTokenWSTrustBinding issuedTokenBinding = new IssuedTokenWSTrustBinding(); issuedTokenBinding.KeyType = SecurityKeyType.AsymmetricKey;
IssuedTokenWSTrustBinding issuedTokenBinding = new IssuedTokenWSTrustBinding(); issuedTokenBinding.SecurityMode = SecurityMode.TransportWithMessageCredential; issuedTokenBinding.KeyType = SecurityKeyType.AsymmetricKey;
IssuedTokenWSTrustBinding issuedTokenBinding = new IssuedTokenWSTrustBinding(); issuedTokenBinding.SecurityMode = SecurityMode.TransportWithMessageCredential;
WindowsWSTrustBinding windowsTrustFeb2005MessageBinding = new WindowsWSTrustBinding(); windowsTrustFeb2005MessageBinding.TrustVersion = TrustVersion.WSTrustFeb2005;
WindowsWSTrustBinding windowsTrustFeb2005MixedBinding = new WindowsWSTrustBinding(SecurityMode.TransportWithMessageCredential); windowsTrustFeb2005MixedBinding.TrustVersion = TrustVersion.WSTrustFeb2005;
WindowsWSTrustBinding windowsTrustFeb2005TransportBinding = new WindowsWSTrustBinding(SecurityMode.Transport); windowsTrustFeb2005TransportBinding.TrustVersion = TrustVersion.WSTrustFeb2005;
CertificateWSTrustBinding certificateTrustFeb2005MessageBinding = new CertificateWSTrustBinding(); certificateTrustFeb2005MessageBinding.TrustVersion = TrustVersion.WSTrustFeb2005;
CertificateWSTrustBinding certificateTrustFeb2005MixedBinding = new CertificateWSTrustBinding(SecurityMode.TransportWithMessageCredential); certificateTrustFeb2005MixedBinding.TrustVersion = TrustVersion.WSTrustFeb2005;
CertificateWSTrustBinding certificateTrustFeb2005TransportBinding = new CertificateWSTrustBinding(SecurityMode.Transport); certificateTrustFeb2005TransportBinding.TrustVersion = TrustVersion.WSTrustFeb2005;
UserNameWSTrustBinding userNameTrustFeb2005MessageBinding = new UserNameWSTrustBinding(); userNameTrustFeb2005MessageBinding.TrustVersion = TrustVersion.WSTrustFeb2005;
UserNameWSTrustBinding userNameTrustFeb2005MixedBinding = new UserNameWSTrustBinding(SecurityMode.TransportWithMessageCredential); userNameTrustFeb2005MixedBinding.TrustVersion = TrustVersion.WSTrustFeb2005;
UserNameWSTrustBinding userNameTrustFeb2005TransportBasicBinding = new UserNameWSTrustBinding(SecurityMode.Transport, HttpClientCredentialType.Basic); userNameTrustFeb2005TransportBasicBinding.TrustVersion = TrustVersion.WSTrustFeb2005;
UserNameWSTrustBinding userNameTrustFeb2005TransportDigestBinding = new UserNameWSTrustBinding(SecurityMode.Transport, HttpClientCredentialType.Digest); userNameTrustFeb2005TransportDigestBinding.TrustVersion = TrustVersion.WSTrustFeb2005;
KerberosWSTrustBinding kerberosTrustFeb2005MixedBinding = new KerberosWSTrustBinding(SecurityMode.TransportWithMessageCredential); kerberosTrustFeb2005MixedBinding.TrustVersion = TrustVersion.WSTrustFeb2005;
issuedTokenBinding.TrustVersion = TrustVersion.WSTrustFeb2005;
This post outlines my thinking on possible ways to stage application and services that are integrated with ACS.
It’s a common practice to have at least three environments – development, test, production - when developing applications and services. Application that use ACS should not be an exception. The key question here is how to move the application between the environments and how to maintain the environments regarding ACS?
One approach is specifically targeted at Windows Azure outlined here. In this post I’d like to explore manual options that are available. In a nut shell, there are two ways:
Consider the following diagram that represents single ACS namespace with 3 configured relying parties and key configuration elements:
What varies here is the realm of each relying party application to reflect on the environment – Dev, Test, Prod. The return URL also varies between the relying parties to reflect on the environments.
Consider the following diagram for the application configuration that uses the above ACS configuration:
When deploying to Windows Azure staging environment the application assigned a URL that includes GUID that’s not known beforehand. It means there is no possible way to properly configure related ACS relying party. To fix this configure the Return URL of Relying Party: Test after deploying to Windows Azure. Another approach is to leverage OnStart event of the WebRole outlined here.
Consider the following diagram that depicts three different ACS namespaces for each environment:
What varies here is the Return URL for each Relying Party while realm is the same. Since there are different ACS namespaces the issuer is different for each one and also the signing certificate would be different. It will reflect on the configuration in the web.config file of the application.
Consider the following diagram that depicts the key attributes in the configuration file of the application:
When deploying the application or a service to Windows Azure staging environment which includes GUID in the URL the ACS testing environment should be updated accordingly with relevant Return URL each time you deploy. That’s not the case though with Dev and Prod environments.