WCF: Centralized authentication over binary bindings

I needed to (well, the nerd in me wanted to) centralize authentication to our SOA farm using an STS (Security Token Service). But since all our services are in-house and 95% of clients of those services are also in-house, we wanted to use binary bindings (TCP and Named Pipes). The only out-of-the-box binding that supports STS authentication is wsFederationHttpBinding, but that is obviously not a binary binding.

So I asked one of the leading authorities on WCF for help (Michele Leroux Bustamante), and she replied with this:

“You can create a custom binding that does federation over TCP. An example of such a binding is:

<custombinding>
    <binding name="netTcpBindingIssuedToken">
        <security authenticationMode="IssuedTokenOverTransport">
            <issuedtokenparameters tokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1"
                keyType="SymmetricKey"
                keySize="256">
                <issuer address="http://localhost/STS/service.svc"/>
            </issuedtokenparameters>
        </security>
        <binarymessageencoding />
        <sslstreamsecurity />
        <tcptransport />
    </binding>
</custombinding>

Since I had absolutely no experience with custom bindings, i started googling. Not so helpful, it turns out. So I bought her book. Very helpful. Not only does it give a good explanation of custom bindings, but gives excellent insight into security and exception handling, which I (after reading her book) realized weren’t my strongest sides.

So to conclude; federated security over binary bindings is definitely possible, but if you are fairly new to this whole WCF thing, pick up a copy of “Learning WCF – A hands on guide“. You won’t regret it, it’s a very extensive but easily read book.

Linq to SQL: Pay attention to the two ways of adding objects

Linq to SQL is a great tool for minimizing data access code in most trivial scenarios. By trivial, I mean no real inheritance, no database specified relationships etc. But I digress…
I have just started a new project where I have some small services that fits Linq to SQL just great. A couple of them are basically just reading and caching of some lists of data that are maintained elsewhere. But then I wanted to save something to the database and, since I am as good as every other developer at reading manuals, I just went in head first. Which caused me a full day of scratching my head. It turns out there are two ways to save a new entity in Linq to SQL: InsertOnSubmit() and Attach()

The first one I tried, and the one that I got from skimming through this blog post, is this:

SomeEntityClass entity = new SomeEntityClass();
entity.Value = someValue;

using (SomeEntityContext db = new SomeEntityContext())
{
db.SomeEntities.Attach(entity);
db.SubmitChanges();
}

As far as I knew at the time, this was the correct way to do it. So I did it. But nothing was written to the database, and no exceptions were thrown. Crap!

After a day of cursing, sweating, playing the harp to calm down, debugging and googling, I finally found the answer. There is a second way to save a new entity in Linq to SQL… WTF?

Here is the way that works:

SomeEntityClass entity = new SomeEntityClass();
entity.Value = someValue;using (SomeEntityContext db = new SomeEntityContext())
{
db.SomeEntities.InsertOnSubmit(entity);
db.SubmitChanges();
}

It turns out that InsertOnSubmit() does just that; Inserts a new instance of the entity type when you call SubmitChanges(). But since I am a terrible reader but an excellent skimmer, I stopped when I came to the Attach() method. The Attach() method is for when you have an entity that already exists in or via the data context. For example, you need to retrieve a customer, change her phone number and store the changes. What you could do is to run an SQL query to get the customer object, do the change and call SubmitChanges().

But what if you have a layer separation here? What if the actual saving and retrieving is done in a DAL but the modification of the phone number is done in the business layer? This is where Attach() comes in. Here you can call the DAL to get a customer entity, make the modifications and send it back into the DAL. The DAL can then fire up a new context and you can use Attach() on the new context with the changed customer entity. The context then recognises this entity and know how to manage the changes done on it.

So, I have to admit that the two methods actually makes some kind of sense. I just wish they would stick the two right next to each other in the intellisense…