Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,125 | Comments: 45,488

filter by tags archive

WCF, Federated Security and Custom Authentication Token, oh my!

time to read 2 min | 217 words

So today I spiked some code to see how hard it was to get federated security to work using WCF. I have never had to do something like that before, but I am familiar with the concepts, at least.

Armed with the WCF federation sample, I set out to build my own.

I failed.

I cannot believe how complex this was. I stopped after I realized that my app.config file passed 200 lines, solely for WCF configuration, I got a lot of unhelpful exceptions from WCF and generally felt that I am wasting my time.

Then I turned to building a custom authentication token, that would have served my need well enough. I started to follow the steps in the sample, but by the fifth class that I had to implement, I had enough. I started counting the number of classes that are required to build a custom authentication token. 11(!) classes!

Sorry, at this point, I back away slowly. This is way too complex for what I need. I solved the problem using a message header, which was a sweet & simple solution to the problem.

I consider myself fairly adept at handling complexity, but oh my god, just trying to touch this piece was scary on many levels.


Chad Myers

Is WCF a layer on top of WS-Deathstar to make it more complicated?


What about getting Rino Security working nice with WCF?

200 lines of XML (I am getting dizzzzzzy)


Couldn't agree more. We actually got federated security working with a custom token and good grief...it's a mess. Delicate, brittle house of cards - slight breath of air and the whole thing comes tumbling down... I've asked why we need to go this route and I hear "best practices" in response. If I need to do single sign-on with a third party then yeah, the whole federated thing can be stitched in via configuration, but if it's within my own app...WTF - don't need it. Already have message / transport level security - what the hell does the rest of it buy you except a bunch of mindless complexity...

Ayende Rahien


That is actually pretty easy. Create an security provider and run from there.

Verwijderde bestanden

that is right, last year I got i working by creating a security provider. After that my custom security token was accepted without a flaw. Dont stop while you're close !


Mark Seemann

Yes, with WCF v1 (in .NET 3.0), Federation can get complex. If you just want to consume a WS-Federation service, or expose such a service, it's actually pretty straight-forward (just use the wsFederationHttpBinding).

However, if you want to create an STS, it get's complicated fast. The same holds true if you want to implement a custom protocol, or similar.

The SDK comes with quite a few samples that should ease your pain a bit.

Still, the WCF team has realised that it could be simpler, and it's my understanding that it will become simpler in future releases. If this subject interests you, you should keep an eye on Vittorio's blog: http://blogs.msdn.com/vbertocci/default.aspx

Right now, this stuff is complex for a number of reasons. One of them has to do with open standards compliance; another with the myriad of extensibility points in WCF.

In any case: Don't be afraid of the XML! With WCF, everything you can put in your app.config file, you can also express imperatively in code.

As an agile developer, you really have to love WCF, but I grant that Federation isn't the simplest scenario to start out with :)


I agree. I wasted way too much time myself learning about WS-Trust and STSs and trying to hack sample code to make it work before I finally gave up. I find it frustrating that Microsoft provides an STS in the cloud for you to use, but doesn't give you the source code to a fully-functional STS to study, modify, and use. I also couldn't find any good answers to making WCF federated security work well with queuing and occasionally-connected smart clients.

Comment preview

Comments have been closed on this topic.


  1. The design of RavenDB 4.0: Physically segregating collections - 16 hours from now
  2. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - about one day from now
  3. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 5 days from now
  4. The design of RavenDB 4.0: Voron has a one track mind - 6 days from now
  5. RavenDB 3.5 whirl wind tour: Digging deep into the internals - 7 days from now

And 12 more posts are pending...

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    03 May 2016 - Making Lucene reliable
  2. RavenDB 3.5 whirl wind tour (14):
    04 May 2016 - I’ll find who is taking my I/O bandwidth and they SHALL pay
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats