WCF is very cool, but configuring WCF can virtually derail a project. Even relatively simple-seeming configurations can take hours or days to get working. It is frustrating! And the most complex part is getting security working.

The Microsoft Patterns and Practices group recently released beta guidance for WCF security (http://www.codeplex.com/wcfsecurityguide), and it is probably the single best resource for information about configuring WCF security you'll find anywhere.

CSLA .NET version 3.0 adds support for Microsoft .NET 3.0 features. This ~120 page ebook covers how to use these new capabilities:

• Windows Presentation Foundation (WPF)
  • Creating WPF forms using business objects
  • Using the new controls in the Csla.Wpf namespace
    • CslaDataProvider
    • Validator
    • Authorizer
    • ObjectStatus
    • IdentityConverter
  • Maximizing XAML and minimizing C#/VB code
• Windows Communication Foundation (WCF)
  • Using the new WCF data portal channel to seamlessly upgrade from Remoting, Web services or Enterprise Services
  • Building WCF services using business objects
  • Applying WCF security to encrypt data on the wire
  • Sending username/password credentials to a WCF service
    • Including use of the new Csla.Security.PrincipalCache class
  • Using the DataContract attribute instead of the Serializable attribute
• Windows Workflow Foundation (WF)
  • Creating activities using business objects
  • Invoking a workflow from a business object
  • Using the WorkflowManager class in the Csla.Workflow namespace

Version 3.0 is an additive update, meaning that you only need to use the .NET 3.0 features if you are using .NET 3.0. CSLA .NET 3.0 is useful for people using .NET 2.0!! These features include:

• Enhancements to the validation subsystem
  • Friendly names for properties
  • Better null handling in the RegExMatch rule method
  • New StringMinLength rule method
  • Help for code generation through the DecoratedRuleArgs class
• Data binding issues
  • Fixed numerous bugs in BusinessListBase to improve data binding behavior
  • Throw exception when edit levels get out of sync, making debugging easier
  • N-level undo changed to provide parity with Windows Forms data binding requirements
• AutoCloneOnUpdate
  • Automatically clone objects when Save() is called, but only when data portal is local
• Enhancements to the authorization subsystem
  • CanExecuteMethod() allows authorization for arbitrary methods

CSLA .NET 3.0 includes numerous bug fixes and some feature enhancements that benefit everyone. If you are using version 2.0 or 2.1, you should consider upgrading to 3.0 to gain these benefits, even if you aren't using .NET 3.0.

See the change logs for version 3.0, version 3.0.1 and version 3.0.2 for a more detailed list of changes.

Using CSLA .NET 3.0 is completely focused on how to use the new features in version 3.0. The book does not detail the internal changes to CSLA .NET itself, so all ~120 pages help you use the enhancements added since version 2.1.

Get the book at store.lhotka.net.
(C# available now, VB available in early October)

Download the 3.0.2 code from the CSLA .NET download page.

I just spent the past few days pulling my hair out trying to get a custom principal to work in WCF.

Google returned all sorts of interesting, but often outdated and/or overly complex results. I kept looking at the techniques people were using, thinking this can't be so hard!!!

Well, it turns out that it isn't that hard, but it is terribly obscure... Fortunately I was able to get help from various people, including Clemens Vasters, Juval Lowy and (in this case most importantly) Christian Weyer. Even these noted WCF experts provided an array of options rather than a unified, simple answer like I'd expected.

My conclusion: while WCF really is cool as can be, it is also a deep plumbing technology that begs for abstraction for use by "normal" people.

Anyway, as a result of my queries, Christian got one of his colleagues to write the blog post I wish I had found a few days ago: www.leastprivilege.com - Custom Principals and WCF.

One of my motivations in researching this issue was for the WCF chapter in my upcoming Using CSLA .NET 3.0 ebook. There's now a comprehensive discussion of the topic in that chapter, starting with the creation and use of X.509 certificates and walking through the whole process of implementing custom authentication and using a custom principal in a WCF service. Dominick's blog post is great, but only covers about a third of the overall solution in the end.

The ebook should be out toward the end of September, for those who are wondering.

I posted previously about an issue where the WCF NetDataContractSerializer was unable to serialize a SecurityException object. Microsoft provided some insight.

It turns out that the constructor of the SerializationException object doesn't set the Action property to anything valid. Before you can serialize a SerializationException with NDCS you must explicitly set the Action property to a valid SecurityAction.

This does mean that NDCS is not compatible with the BinaryFormatter in this case, but at least there's a workaround/solution.

I've now updated CSLA .NET 3.0 to explicitly set the Action property any time a SecurityException is thrown, thus allowing the WCF data portal channel to return valid details about the nature of any exception.

The WCF NetDataContractSerializer is an almost, but not quite perfect, replacement for the BinaryFormatter.

The NDCS is very important, because without it WCF could never be viewed as a logical upgrade path for either Remoting or Enterprise Services users. Both Remoting and Enterprise Services use the BinaryFormatter to serialize objects and data for movement across AppDomain, process or network boundaries.

Very clearly, since WCF is the upgrade path for these core technologies, it had to include a serialization technology that was functionally equivalent to the BinaryFormatter, and that is the NDCS. The NDCS is very cool, because it honors both the Serializable model and the DataContract model, and even allows you to mix them within a single object graph.

Unfortunately I have run into a serious issue, where the NDCS is not able to serialize the System.Security.SecurityException type, while the BinaryFormatter has no issue with it.

The issue shows up in CSLA in the data portal, because it is quite possible for the server to throw a SecurityException. You'd like to get that detail back on the client so you can tell the user why the server call failed, but instead you get a "connection unexpectedly closed" exception instead. The reason is that WCF itself blew up when trying to serialize the SecurityException to return it to the client. So rather than getting any meaningful result, the client gets this vague and nearly useless exception instead.

By the way, if you want to see the failure, just run this code:

    Dim buffer As New System.IO.MemoryStream
    Dim formatter As New System.Runtime.Serialization.NetDataContractSerializer
    Dim ex As New System.Security.SecurityException("a test")
    formatter.Serialize(buffer, ex)

And if you want to see it not fail run this code:

    Dim buffer As New System.IO.MemoryStream
    Dim formatter As New System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
    Dim ex As New System.Security.SecurityException("a test")
    formatter.Serialize(buffer, ex)

I've been doing a lot of work with the NDCS over the past several months. And this is the first time I've encountered a single case where NDCS didn't mirror the behavior of the BinaryFormatter - which is why I do think this is a WCF bug. Now just to get it acknowledged by someone at Microsoft so it can hopefully get fixed in the future...

The immediate issue I face is that I'm not entirely sure how to resolve this issue in the data portal. One (somewhat ugly) solution is to catch all exceptions (which I actually do anyway), and then scan the object graph that is about to be returned to the client to see if there's a SecurityException in the graph. If so perhaps I could manually invoke the BinaryFormatter and just return a byte array. The problem with that is in the case where the object graph is a mix of Serializable and DataContract objects - in which case the BinaryFormatter won't work because it doesn't understand DataContract...

In the end I may just have to leave it be, and people will need to be aware that they can never throw a SecurityException from the server...