Zulfiqar's weblog

ExtractSAMLAssertion

Wed, 10 Mar 2010 14:57:28 GMT

Few people have asked me for the source code of ExtractSAMLAssertion helper method/class, which I have used in my article and blog posts. So here you go...

Please note this is just raw test code and doesn’t have any error checking and other related goodies.

class Program

{

static void Main(string[] args)

{

var binding = new WSHttpBinding(SecurityMode.Message);

binding.Security.Message.ClientCredentialType = MessageCredentialType.None;

binding.Security.Message.EstablishSecurityContext = false;

var fac = new WSTrustChannelFactory(binding, "http://localhost:9000/STS");

fac.Credentials.ServiceCertificate.Authentication.CertificateValidationMode = X509CertificateValidationMode.None;

fac.Open();

var rst = new RequestSecurityToken {

AppliesTo = new EndpointAddress("http://localhost"),

RequestType = WSTrustFeb2005Constants.RequestTypes.Issue

};

var token = fac.CreateChannel().Issue(rst) as GenericXmlSecurityToken;

var rpCert = new X509Certificate2("localhost.pfx", "a");

var xml = ExtractSAMLAssertion(token, rpCert);

}

private static string ExtractSAMLAssertion(GenericXmlSecurityToken token, X509Certificate2 rpCert)

{

string txtAssertion = string.Empty;

var handlerCol = SecurityTokenHandlerCollection.CreateDefaultSecurityTokenHandlerCollection();

var han = handlerCol.OfType<EncryptedSecurityTokenHandler>().FirstOrDefault();

if (han != null)

{

han.Configuration.ServiceTokenResolver = new EncryptedKeyResolver(rpCert);

var sr = new StringReader(token.TokenXml.OuterXml);

var rdr2 = XmlReader.Create(sr);

var rtok = han.ReadToken(rdr2) as SamlSecurityToken;

var stat = rtok.Assertion.Statements[0];

var ms = new MemoryStream();

var memWriter = XmlDictionaryWriter.CreateTextWriter(ms);

stat.WriteXml(memWriter, new SamlSerializer(), new WSSecurityTokenSerializer());

memWriter.Flush();

ms.Seek(0, SeekOrigin.Begin);

txtAssertion = new StreamReader(ms).ReadToEnd();

}

return txtAssertion;

}

class EncryptedKeyResolver : SecurityTokenResolver

{

// Relying party certificate - must hold private key.

X509Certificate2 rpCert;

public EncryptedKeyResolver(X509Certificate2 rpCert)

{

this.rpCert = rpCert;

}

protected override bool TryResolveSecurityKeyCore(SecurityKeyIdentifierClause keyIdentifierClause, out SecurityKey key)

{

key = null;

try

{

var ekec = keyIdentifierClause as EncryptedKeyIdentifierClause;

if (ekec != null)

{

switch (ekec.EncryptionMethod)

{

case "http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p":

{

var encKey = ekec.GetEncryptedKey();

var rsa = rpCert.PrivateKey as RSACryptoServiceProvider;

var decKey = rsa.Decrypt(encKey, true);

key = new InMemorySymmetricSecurityKey(decKey);

return true;

}

var data = ekec.GetEncryptedKey();

var id = ekec.EncryptingKeyIdentifier;

}

catch (Exception eexx)

{

Console.WriteLine(eexx);

throw eexx;

}

return false;

}

protected override bool TryResolveTokenCore(SecurityKeyIdentifierClause keyIdentifierClause, out SecurityToken token)

{

throw new NotImplementedException();

}

protected override bool TryResolveTokenCore(SecurityKeyIdentifier keyIdentifier, out SecurityToken token)

{

throw new NotImplementedException();

}

Introducing Workflow Security Pack

Tue, 23 Feb 2010 21:23:08 GMT

Have you already started serious development with WF 4 and found security limitations?

Have you struggled to implement authenticated messaging, claims-based security, role-based security and other security features in workflow solutions?

WF 4 is a highly extensible framework so most of these features can be built using the WF extensibility model, but wouldn’t it be nice to have all of these security features available in an easy to use activity library?

Here comes the Workflow Security Pack (WFSP) project... WFSP is a collection of activities and associated plumbing to enable key security scenarios in WF 4. WFSP activities blend with the rest of the WF to bring end-to-end integrated security into workflow solutions. The following diagram shows the initial set of activities which are part of WFSP.

Following are some of the scenarios enabled by WFSP:

1. Authenticated messaging

a. Enables the use of various credentials with Send activity

b. Follows exactly the same model when using a Username token or a Saml token issued by an STS

2. Role-based security

a. Enables principal permission based authorization on the Receive activity

b. Supports standard RoleProvider extensibility model

3. Claims-based security

a. Ability to acquire a SAML token using the WS-Trust protocol

b. Ability to pass this token to a SAML secured service using WS-Security

4. End-to-end Claim-based delegation

a. Ability to use any token as an ActAs token

5. Transparent handling of tokens in a long-running environment

a. Enlisted tokens are preserved during persist and reload cycles

6. Impersonation and Delegation support

a. Ability to impersonate incoming Identity on Receive side

b. Ability to impersonate a User identity on the Send side

c. Ability to call a backend service from the Impersonated scope (Kerberos delegation)

7. WCF OperationContext access in a thread-agnostic way

In future posts, I’ll take an in-depth look into each of activities above and various scenarios enabled by these activities. Stay tuned.

Adding Dynamic methods to a WCF Service

Zulfiqar — Fri, 05 Feb 2010 16:25:46 GMT

Someone asked me if it’s possible to add a Ping method to every service contract without repeatedly defining it in each service contract? The answer is yes & and it’s fairly simply too.

Here I have a LoginService, which require that implicit Ping method (DateTime Ping(){})like all other service.

[ServiceContract]

class LoginService

{

[OperationContract]

public bool Login(string userName, string password)

{

return true;

}

This is how you would configure your host for these implicit methods.

class Program

{

static void Main(string[] args)

{

var sh = new ServiceHost(typeof(LoginService), new Uri("http://localhost:9001"));

GeneratePingMethod(sh);

sh.Open();

Console.ReadLine();

sh.Close();

}

Please note “GeneratePingMethod” adds the Ping method to every endpoint. I’m simply creating the operation using the WCF description API and adding it into the description tree. PingImplementationBehavior plugs in a custom OperationInvoker which calls the actual Ping implementation.

private static void GeneratePingMethod(ServiceHost sh)

{

foreach (var endpoint in sh.Description.Endpoints)

{

var cd = endpoint.Contract;

var od = new OperationDescription("Ping", cd);

var inputMsg = new MessageDescription(cd.Namespace + cd.Name + "/Ping", MessageDirection.Input);

var outputMsg = new MessageDescription(cd.Namespace + cd.Name + "/PingResponse", MessageDirection.Output);

var retVal = new MessagePartDescription("PingResult", cd.Namespace); ;

retVal.Type = typeof(DateTime);

outputMsg.Body.ReturnValue = retVal;

od.Messages.Add(inputMsg);

od.Messages.Add(outputMsg);

od.Behaviors.Add(new DataContractSerializerOperationBehavior(od));

od.Behaviors.Add(new PingImplementationBehavior());

cd.Operations.Add(od);

}

class PingImplementationBehavior : IOperationBehavior

{

public void AddBindingParameters(OperationDescription operationDescription, BindingParameterCollection bindingParameters)

{ }

public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)

{ }

public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)

{

dispatchOperation.Invoker = new PingInvoker();

}

public void Validate(OperationDescription operationDescription)

{ }

}

Again a fairly simple invoker which is tightly coupled to the signature of Ping method.

class PingInvoker : IOperationInvoker

{

public object[] AllocateInputs()

{

return new object[0];

}

public object Invoke(object instance, object[] inputs, out object[] outputs)

{

outputs = new object[0];

return Ping();

}

public IAsyncResult InvokeBegin(object instance, object[] inputs, AsyncCallback callback, object state)

{

throw new NotImplementedException();

}

public object InvokeEnd(object instance, out object[] outputs, IAsyncResult result)

{

throw new NotImplementedException();

}

public bool IsSynchronous

{

get { return true; }

}

public static DateTime Ping()

{

return DateTime.Now;

}

Authenticated messaging in WF 4

Tue, 19 Jan 2010 16:44:20 GMT

Authenticated messaging is one limitation in WF 4 as currently there is no API for setting up credentials to be used with a Send activity. Having said that, ChannelFactory used by Send activity still picks up the behaviour configuration from the config file.

So you can potentially write a custom behaviour to supply additional credentials to the Send activity. Let’s see a simple clientCredentialsAdapter behaviour which will enable you to setup userName/Password in config file. It’s almost always a bad idea to keep unencrypted password in config files so it is recommended that you should use config encryption to encrypt the behaviour section.

</serviceCertificate>

</clientCredentials>

</clientCredentialsAdapter>

</behavior>

At this point, you can configure this behaviour on an endpoint used by a Send activity. This change will enable Send activity to use this userName/Password for securing outgoing messages.

public class ClientCredentialsAdapterBehavior : IEndpointBehavior

{

ClientCredentialsAdapterBehaviorElement configElement;

public ClientCredentialsAdapterBehavior(ClientCredentialsAdapterBehaviorElement configElement)

{

this.configElement = configElement;

}

public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters){}

public void ApplyClientBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.ClientRuntime clientRuntime)

{

var clientCredentials = endpoint.Behaviors.Find<ClientCredentials>();

Adapt(clientCredentials);

}

public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher) { }

public void Validate(ServiceEndpoint endpoint){}

void Adapt(ClientCredentials orignalCredentials)

{

orignalCredentials.UserName.UserName = configElement.UserName.UserName;

orignalCredentials.UserName.Password = configElement.UserName.Password;

}

So that was simpleJ What about a scenario where you have userName/Password as part of workflow state and you want to use that instead?

Well, in that case there is more work involved which I’ll discuss in next post.

Using Request Headers for Metadata Address

Thu, 14 Jan 2010 19:44:42 GMT

WCF by default adds the listen address of the endpoints in the WSDL so in a scenario where the private address of the server is different from the public address you get incorrect endpoint address in WSDL.

For example if a service is listening on http://localhost:7721/ and you access its metadata using a virtual IP http://102.212.0.117/?wsdl, you get following:

Now this behavior might not work in certain scenarios and you want the metadata generation to dynamically pick the address from the request headers, similar to ASMX web services.

UseRequestHeadersForMetadataAddressBehavior enables exactly this. This opt-in behavior sets the address of endpoints dynamically, based on the request header.

Like all other WCF behaviors, this behavior can be enabled either in the code or config.

sh.Description.Behaviors.Add(new UseRequestHeadersForMetadataAddressBehavior());

<system.serviceModel>

</behavior>

</serviceBehaviors>

</behaviors>

</system.serviceModel>

This behavior is added in .NET 4.0 and there is a QFE available for 3.5 SP1: http://support.microsoft.com/kb/971842

PrincipalPermission Authorization in WF 4

Tue, 12 Jan 2010 18:28:19 GMT

In last post, I have shown you how to get hold of OperationContext when using messaging activities. Once you got hold of OperationContext, you can use it to perform many useful tasks and one of them is Authorization. Let’s start by defining a Scope activity to hook our IReceiveMessageCallback implementation.

[Designer(typeof(PrincipalPermissionScopeDesigner))]

public class PrincipalPermissionScope : NativeActivity

{

public InArgument<string> PrincipalPermissionName { get; set; }

public InArgument<string> PrincipalPermissionRole { get; set; }

public Activity Body { get; set; }

protected override void Execute(NativeActivityContext context)

{

var name = this.PrincipalPermissionName.Get(context);

var role = this.PrincipalPermissionRole.Get(context);

var principalPermission = new PrincipalPermission(name, role);

context.Properties.Add("AuthorizationManager",

new AuthorizationManager(principalPermission));

context.ScheduleActivity(this.Body);

}

As part of Scope activity execution, I have added my ReceiveMessageCallback in execution properties collection. This enables our callback to be called for every message received by any activity inside the Scope. Once we have access to OperationContext (which is the only as the only parameter of the callback) we can use it to perform authorization.

[DataContract]

class AuthorizationManager : IReceiveMessageCallback

{

[DataMember]

PrincipalPermission principalPermission;

public AuthorizationManager(PrincipalPermission principalPermission)

{

this.principalPermission = principalPermission;

}

public void OnReceiveMessage(

System.ServiceModel.OperationContext operationContext,

ExecutionProperties activityExecutionProperties)

{

var currentPrincipal = Thread.CurrentPrincipal;

var isPrincipalSet = false;

var targetPrincipal = GetPrincipal(operationContext);

try

{

if (targetPrincipal != null)

{

Thread.CurrentPrincipal = targetPrincipal;

isPrincipalSet = true;

principalPermission.Demand();

}

catch (SecurityException)

{

throw SecurityUtility.CreateAccessDeniedFaultException();

}

finally

{

if (isPrincipalSet)

Thread.CurrentPrincipal = currentPrincipal;

}

And with a customer designer, this is how it look like

Article on AD FS 2.0

Sun, 13 Dec 2009 12:28:51 GMT

My article on AD FS 2.0 was published in November issue of MSDN magazine. Here is the URL.

http://msdn.microsoft.com/en-us/magazine/ee335705.aspx

Managing OperationContext in WF 4

Sun, 13 Dec 2009 12:26:43 GMT

Managing OperationContext in WF 4 using the ISendMessageCallback & IReceiveMessageCallback

WF 4 raised the level of abstraction for writing workflow services and their clients by defining Send & Receive messaging activities. These activities hides lot of WCF plumbing from you and as result, some useful components like OperationContext are also not available in the usual WCF way. For example,

Ø When using Send activity, you never see the ChannelFactory/Channel so you can’t scope an OperationContext around them.

Ø When using Receive activity, activities following the Receive might execute on a different thread (than the WCF dispatcher thread) in which case you again wouldn’t get OperationContext.

If you done any WCF programming, you would agree that OperationContext can be very useful on both Send/Receive side:

Ø On the send side, you can use OperationContext for sending additional message headers as part of the outgoing message or you can use OperationContext to add additional message properties to the outgoing message.

Ø On the receive side, you can use OperationContext to retrieve very useful information including but not limited to security information related to the incoming message.

So in short, access to OperationContext on Send/Receive side can be very useful and luckily WF 4 has enabled this using a callback mechanism based on IReceiveMessageCallback & ISendMessageCallback.

IReceiveMessageCallback(s) are invoked just after the message is received by a Receive activity. Similarly, ISendMessageCallback(s) are invoked just before the message is sent on wire.

To attach these callback(s) to Send & Receive activities, they must be available as execution properties when Send/Receive executes. Execution properties are WF mechanism to enable Thread Local Storage (TLS) in a thread agnostic way. A common method of adding execution properties to and activity is to create a parent scope activity and set the execution properties as part of parent execution. Here is an example.

public class OperationContextScope : NativeActivity

{

public Activity Body { get; set; }

protected override void CacheMetadata(NativeActivityMetadata metadata)

{

metadata.AddChild(this.Body);

}

protected override void Execute(NativeActivityContext context)

{

context.Properties.Add("MessageInspector", new SendMessageInspector());

context.ScheduleActivity(this.Body);

}

[DataContract]

class SendMessageInspector : ISendMessageCallback

{

public void OnSendMessage(OperationContext operationContext)

{

var h1 = MessageHeader.CreateHeader("yourName", "urn:personal", "zuahmed");

operationContext.OutgoingMessageHeaders.Add(h1);

}

Once you defined a scope activity like above you can just wrap your actual Send/Receive inside this scope to activate your inspector.

WorkflowInvoker.Invoke(

new OperationContextScope

{

Body =

new Send { OperationName = "Ping", ServiceContractName = "IPingService", EndpointConfigurationName = "PingEpr" }

}

);

IReceiveMessageCallback and Receive activity is exactly the same and I leaving that as an exercise for the readers J

In this post, I have shown you a general purpose mechanism to interact with an OperationContext while using WF 4 messaging activities. In next few posts, I’ll use this mechanism to add some very useful security features to WF 4. Stay tuned...

Durable Duplex Messaging in .Net 4 Beta2

Zulfiqar — Wed, 28 Oct 2009 12:10:25 GMT

Here I talked about couple of approaches to enable durable duplex messaging in .Net 3.5.

.NET 4 has added first class support for durable duplex messaging by extending Context Exchange Protocol to include a CallbackContext. So in addition to instanceId, a client application can send a callback context as part of the call.

Service, upon receiving the message, will start the long running work and when it needs to callback to client, it can simply use the address from the callback context.

From API perspective – a new property “ClientCallbackAddress” is added to ContextBindingElement. This property is also exposed on some higher level bindings like wsHttpContextBinding.

A new CallbackContextMessageProperty is also added to manipulate callback context from the application code.

< bindings>

< wsHttpContextBinding>

< binding name="noSec" clientCallbackAddress="http://localhost:7080">

< security mode="None"/>

binding>

wsHttpContextBinding>

bindings>

Any messages sent using above binding will have a callback context attached to it. Please note callback context is only supported with SOAP based context exchange and that’s why clientCallbackAddress property is NOT exposed on basicHttpContextBinding as it uses HTTP cookies for context exchange.

var cf = new ChannelFactory<IRequestChannel>(new WSHttpContextBinding("noSec"), >

new EndpointAddress("http://localhost:8975/"));

var ccmp = new CallbackContextMessageProperty(new Dictionary<string,string>()); >

var msg = Message.CreateMessage(MessageVersion.Default, "urn:foo", "");

msg.Properties.Add(CallbackContextMessageProperty.Name, ccmp);

cf.CreateChannel().Request(msg);

This will produce following SOAP envelop and you can see CallbackContext header is added in outgoing message.

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">

< s:Header>

< a:Action s:mustUnderstand="1">urn:fooa:Action>

< a:MessageID>urn:uuid:c7c03178-fa84-400e-8673-ad1ed28f0f79a:MessageID>

< a:ReplyTo>

< a:Address>http://www.w3.org/2005/08/addressing/anonymousa:Address>

a:ReplyTo>

< CallbackEndpointReference>

< a:Address>http://localhost:7080/a:Address>

< a:ReferenceParameters>

< Context xmlns="http://schemas.microsoft.com/ws/2006/05/context"/>

a:ReferenceParameters>

CallbackEndpointReference>

CallbackContext>

< a:To s:mustUnderstand="1">http://localhost:8975/a:To>

s:Header>

< s:Body>

< string xmlns="http://schemas.microsoft.com/2003/10/Serialization/"/>

s:Body>

s:Envelope>

On the server side, you can pick up the CallBackContext from the Message Properties and use it for call-backs. So far I have shown kind of a manual way of dealing with callback context. Workflow services in .Net 4 along with correlation feature has really simplified all this and you never need to muck with CallbackContextMessageProperty etc.

In your client workflow, simply make sure you have an active correlation handle on your send activity and then use a binding capable of transporting callback context (e.g. wsHttpContextBinding mentioned earlier)

In your server side workflow, simply make sure that Receive and Send (used for callback) activities are correlated either using implicitly or explicit correlation and that’s it.

You don’t need to specify Endpoint Address on your Send activity and it will automatically pick it from CallbackContext.

Pass-through SAML tokens & Secure Conversation (Part2)

Sun, 07 Jun 2009 13:05:57 GMT

Few people have contacted me regarding follow-up on my last post so this post continues where the last one left off.

To keep the API simple, I have created few extension methods. Let’s first review these.

public static class Extensions

{

public static void EnableSamlTokenCaching(this ServiceHostBase source)

{

var orignal = source.Description.Behaviors.Remove<ServiceCredentials>();

source.Description.Behaviors.Add(new ServiceCredentialsEx(orignal));

}

public static SamlSecurityToken GetIncommingSamlToken(this ServiceSecurityContext source)

{

var policy = source.AuthorizationPolicies.OfType<SamlTokenCachingPolicy>().FirstOrDefault();

if (policy != null)

return policy.IncommingSamlToken;

return null;

}

public static void EnableSamlTokenFlow<TChannel>(this ClientBase<TChannel> source, SamlSecurityToken tokenToFlow) where TChannel : class

{

var orignal = source.Endpoint.Behaviors.Remove<ClientCredentials>();

source.Endpoint.Behaviors.Add(new ClientCredentialsWrapper(orignal));

}

EnableSamlTokenCaching is what you have to call to enable SAML token caching functionality for a particular ServiceHost. Here is an example of a simple host (created using a custom factory (IIS/WAS hosted scenario)) being configured with this API

public class EchoServiceHostFactory : ServiceHostFactoryBase

{

public override ServiceHostBase CreateServiceHost(string constructorString, Uri[] baseAddresses)

{

var sh = new ServiceHost(typeof(EchoService), baseAddresses);

sh.EnableSamlTokenCaching();

return sh;

}

The highlighted call simply injects couple of customized components (interceptors) into WCF’s security framework. Specifically it is injecting a new customized SamlSecurityTokenAuthenticator, which wraps the original authenticator and simply delegates all calls to it.

SamlSecurityTokenAuthenticator is called during secure conversation handshake. Here our custom authenticator (SamlSecurityTokenAuthenticatorEx) enables us to get hold of the incoming SAML token etc.

public class ServiceCredentialsEx : ServiceCredentials

{

public ServiceCredentialsEx(ServiceCredentials other)

: base(other){}

public override SecurityTokenManager CreateSecurityTokenManager()

{

return new ServiceCredentialsSecurityTokenManagerEx(this);

}

protected override ServiceCredentials CloneCore()

{

return new ServiceCredentialsEx(this);

}

public class ServiceCredentialsSecurityTokenManagerEx : ServiceCredentialsSecurityTokenManager

{

public ServiceCredentialsSecurityTokenManagerEx(ServiceCredentials parent)

: base(parent){}

public override SecurityTokenAuthenticator CreateSecurityTokenAuthenticator(SecurityTokenRequirement tokenRequirement, out SecurityTokenResolver outOfBandTokenResolver)

{

var authenticator = base.CreateSecurityTokenAuthenticator(tokenRequirement, out outOfBandTokenResolver);

if (authenticator is SamlSecurityTokenAuthenticator)

return new SamlSecurityTokenAuthenticatorEx((SamlSecurityTokenAuthenticator)authenticator);

return authenticator;

}

Inside SamlSecurityTokenAuthenticatorEx, I’m simply creating an additional token caching policy and adding it to the collection of policies created by default SAML token authenticator.

public class SamlSecurityTokenAuthenticatorEx : SamlSecurityTokenAuthenticator

{

SamlSecurityTokenAuthenticator wrapped;

public SamlSecurityTokenAuthenticatorEx(SamlSecurityTokenAuthenticator wrapped)

: base(new List<SecurityTokenAuthenticator>())

{

this.wrapped = wrapped;

}

protected override ReadOnlyCollection<IAuthorizationPolicy> ValidateTokenCore(SecurityToken token)

{

var orignalPolicies = wrapped.ValidateToken(token);

List<IAuthorizationPolicy> finalPolicies = new List<IAuthorizationPolicy>(orignalPolicies);

finalPolicies.Add(new SamlTokenCachingPolicy((SamlSecurityToken)token));

return finalPolicies.AsReadOnly();

}

My SamlTokenCachingPolicy is just a wrapped around the cached token.

public class SamlTokenCachingPolicy : IAuthorizationPolicy

{

public const string PolicyID = "{32835E28-3ED4-42d4-A2EA-FA71E13AF51F}";

public SamlTokenCachingPolicy(SamlSecurityToken token)

{

this.IncommingSamlToken = token;

}

public bool Evaluate(EvaluationContext evaluationContext, ref object state)

{

return true;

}

public ClaimSet Issuer

{

get { throw new System.NotImplementedException(); }

}

public string Id

{

get { return PolicyID; }

}

public SamlSecurityToken IncommingSamlToken { get; private set; }

}

IAuthorizationPolicy model nicely aligns with WCF security framework (so I have used it here). If you are not comfortable with this approach, you could get the same results by choosing a different caching strategy.

Inside your service method you can get hold of the incoming SAML token using following piece of code.

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Prefix)]

public class EchoService : IEchoService

{

public string Echo(string input)

{

// Get token from incoming security context..

var samlToken = OperationContext.Current.ServiceSecurityContext.GetIncommingSamlToken();

}

GetIncommingSamlToken is again an extension which extracts the actual token from my custom AuthorizationPolicy(SamlTokenCachingPolicy).

public static SamlSecurityToken GetIncommingSamlToken(this ServiceSecurityContext source)

{

var policy = source.AuthorizationPolicies.OfType<SamlTokenCachingPolicy>().FirstOrDefault();

if (policy != null)

return policy.IncommingSamlToken;

return null;

}

Oh, this post is already way too long. Probably next time I will show you, how to pass this token to backend services (sharing the same certificate).

Duplex communication with .Net 3.5 Workflow Services

Fri, 05 Jun 2009 21:28:52 GMT

Workflow Services was introduced as part of .Net 3.5 and enables us to use WF workflows as implementation of our WCF services. Workflows are long running by nature so the usual WCF duplex messaging constructs (where correlation between client & server is done based on actual physical connection/socket) are not suitable for most cases. Primarily because it is simply not possible or practical to keep a socket open until workflow finishes its processing (which could potentially take days to produce any meaningful response).

So channel based WCF duplex messaging is not good for long running scenarios. So how can we achieve duplex messaging in long running world?

The general guidance is to use an explicit callback channel (sometime known as “back channel”) for notifications. You can argue that addressability of the client (who may be behind NAT/Firewall) is a real blocker for explicit back channel & I totally agree. However with Relay technologies like .Net Service Bus, reaching to the client endpoints is not an issue anymore hence explicit back channel is much more practical/feasible option now.

Anyways in this post I will show you, how we can achieve durable duplex messaging using Workflow Services. Here is a basic scenario:

Frond end service (orange box) is a long running workflow service – actual service implementation is a WF workflow so it can go idle, persist, sit in the database & brought back into memory if and when needed (all the usual stuff).

Now with above setup if we do usual request-reply messaging – Send activity will simply wait for the reply, workflow will stay in memory & ultimately underlying WCF call will timeout and bad things will happen (workflow might terminate etc).

So first change we have to do is to move the “wait for reply logic” out of the workflow into the host. With this change workflow can go idle, persist and ultimately gets unloaded while host is still listening for the response. On the response, host can bring workflow back into memory and resume the execution. Important takeaway is that we don’t have to do all this ourselves. Workflow Services & associated “context-exchange protocol” can do most of this for us.

Following is the implementation of front end service...

Dowork is a one-way call. As part of Dowork I’m also passing instanceId of the current workflow along with a callback address (using the standard WS-Addressing ReplyTo header - for protocol purists: this might not be the correct use of ReplyTo header but I’m using it here to keep things simple). So essentially I’m saying “please call me back on this number, when you are done.” J

Dowork call returns immediately by triggering long running work in the Backend service. Workflow will become idle & can potentially persist.

To override the value of default replyTo header, I have created a simple message inspector.

class ReplyToInspector : IClientMessageInspector

{

EndpointAddress replyTo;

public ReplyToInspector(EndpointAddress replyTo)

{

this.replyTo = replyTo;

}

#region IClientMessageInspector Members

public void AfterReceiveReply(ref System.ServiceModel.Channels.Message reply, object correlationState)

{

}

public object BeforeSendRequest(ref System.ServiceModel.Channels.Message request, IClientChannel channel)

{

request.Headers.ReplyTo = replyTo;

return null;

}

#endregion

}

And this can be configured in config file as:

</behavior>

</endpointBehaviors>

Backend service is standard WCF service – doing callbacks using the usual ChannelFactory stuff. The important bit (highlighted) is the explicit context management.

public void Dowork(Guid instanceId)

{

Console.WriteLine("Doing long running work...");

for (int i = 0; i < 10; i++)

{

Console.Write("...");

Thread.Sleep(1000);

}

Console.WriteLine();

try

{

Console.WriteLine("Sending response...");

SendResults(instanceId, OperationContext.Current.IncomingMessageHeaders.ReplyTo);

}

catch (Exception exp)

{

Console.WriteLine("Failed: " + exp.ToString());

}

private void SendResults(Guid instanceId, EndpointAddress remoteAddress)

{

var binding = new BasicHttpContextBinding();

var cf = new ChannelFactory<IBackendCallback>(binding, remoteAddress);

var proxy = cf.CreateChannel();

var cc = proxy as IContextChannel;

using (new OperationContextScope(cc))

{

var cmp = new ContextMessageProperty();

var cm = cc.GetProperty<IContextManager>();

cm.Enabled = false;

cmp.Context["instanceId"] = instanceId.ToString();

OperationContext.Current.OutgoingMessageProperties.Add(ContextMessageProperty.Name, cmp);

proxy.LongRunningOperationCompleted(new OperationOutput { Id = 22, Status = "Done.." });

}

In Dowork, I’m passing instanceId as method’s signature however you can easily pass this data as part of context header (remmeber context header is property bag -- IDictionary<string,string>)

In the SendResults – I’m creating approparite context header – so that WorflowServiceHost can connect this callback to the correct instance & correct activity inside that instance. WorkflowServiceHost will also load the workflow if it got persisted.

I’m attaching complete solution with this. In next post, I will talk about durable messaging enhancements added in .Net 4.0 Beta 1.

Stay tuned...

Download: DurableMessaging.zip