+972 52-548-6969
WCF, Federated Security and Custom Authentication Token, oh my!
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.
Comments
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...
Yitzchok,
That is actually pretty easy. Create an security provider and run from there.
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 !
regards
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