Zulfiqar's weblog

Architecture, security & random .Net

Archive for June, 2010

Exposing Service metadata via HTTP Get on the Service Bus

Posted by zamd on June 30, 2010

.Net Service Bus currently doesn’t support exposing metadata via HTTP Get. Currently it only supports WS-MetadataExchange based metadata generation. I explored various options and came with following solution which seems to be working fine.

  • Expose a REST endpoint with HTTP Get enabled
  • From the implementation of this endpoint, forward the request to real HTTP Get endpoint
  • Send the response data back to the client via Service Bus
  • I have also used the new .Net 4.0 UseRequestHeadersForMetadataAddressBehavior to fix the port and host name in the generated WSDL file

I have packaged all of the above in a custom service behaviour and you can now enable this feature by simply adding this behaviour (line 16) to your service host.


  1.     var cred = new TransportClientEndpointBehavior();
  2.     cred.CredentialType = TransportClientCredentialType.SharedSecret;
  4.     cred.Credentials.SharedSecret.IssuerName = "owner";
  5.     cred.Credentials.SharedSecret.IssuerSecret = "SHARED-SECERET";
  7.     var baseAddress = ServiceBusEnvironment.CreateServiceUri("http", "ServiceNAMESpace", "");
  9.     var sh = new ServiceHost(typeof(EchoService), baseAddress);
  10.     var binding = new WS2007HttpRelayBinding(EndToEndSecurityMode.None,RelayClientAuthenticationType.None);
  11.     var endpoint = sh.AddServiceEndpoint(typeof(IEchoService), binding, "Echo");
  12.     endpoint.Behaviors.Add(cred);
  14.     //Add SBMetadataBehavior to enable http get metadata via ServiceBus
  15.     sh.Description.Behaviors.Add(new SBMetadataBehavior("metadata"));
  17.     sh.Open();

I have upload the complete solution so feel free to download and experiment.

Posted in Windows Azure AppFabric | Leave a Comment »

Integrating WIF, WF 4.0 & AppFabric: Claims-Based-Delegation

Posted by zamd on June 3, 2010

Extending upon my last post, where I have talked about basic integration, this post will go into the details of claims-based-delegation in WF 4.0 & AppFabric.

Again I’ll be using activities from the Workflow Security Pack. Let’s start with a diagram which captures the main components of solution and their interactions:


  1. Unauthenticated user browse to web application protected by WIF modules.
  2. WIF redirects user to Passive STS for authentication
  3. User authenticates @ passive STS and is redirected back to the ASP.net app along with the Issued Token. WIF modules processes this token and upon successful validation of the token, user is logged into the application. I have configured SaveBootstrapTokens on this app, so the raw incoming token is preserved as part of IClaimsIdentity.
  4. Users click the “Call Service” link to invoke following client workflow. GetBootstrapToken activity reads the bootstrap token and enlist it with the SecurityTokenHandle (specified on the InitializeActAsToken activity) as an ActAs token.image
  5. InitializeSamlSecurityToken activity issues a request (RST) to acquire a SAML token from the STS using the ActAs token enlisted in step 4. InitializeSamlSecurityToken is able to see the ActAs token (enlisted by InitializeActAsToken activity)  because both of these activities share the same SecurityTokenHandle. At this stage, Web App is authenticated by STS using windows authentication while ActAs token is a Saml token (acquired using forms authentication in step 3). The final Saml token will contain claims for both immediate (web app) and original caller (authenticated user).
  6. TokenFlowScope activity along with the workflowCredentials behaviour (configured on the endpoint used by the Echo activity) enhances the WCF security pipeline to attach the Saml token (acquired in step 5) with the outgoing message. As part of it’s execution, TokenFlowScope will detect that Echo activity requires a Saml token, it will then check it’s enlisted tokens to see if it can satisfy the token requirements of the Echo activity. In this example, there is already a Saml token enlisted with the handle so TokenFlowScope simply attaches that token with the outgoing message.

I have attached complete solution with this post. I tried to keep the solution self-contained by using file-based certificates and other shortcuts so hopefully you should be able to get it working by just hitting Ctrl-F5 🙂

Feel free to download and experiment and let me know your thoughts…

Posted in WF4, WFSP, WIF | 10 Comments »