Microsoft have produced a beta of the WCF  Security Guide.

I'm chuffed to bits to see this appear. I've waited for quite a while to see some of the older guides updated, and this is very good quality.

I worked with a security consultancy last year that gave their graduates the older Patterns and Practices Guides on the first day at work. The new graduates all wondered why they'd not been given the documents at university!

One of the strengths of these documents is that they've been tried and tested. This is proven by the code samples that are included - so many questions are answered by providing this.

Several solutions are included, which can be mapped on to your requirements. This is what design patterns are all about for me - integrating parts of the application together, rather than being lost in classes and interfaces. This is extremely useful, as security often changes (fundamentally) the architecture of an application. Having a mapping from requirements to architecture saves a great deal of time and money, as there is less change later in development. The overall security integration can be done sooner.

What are the downsides? Well, they're vey few in number:

Only Microsoft products are considered. Shame, as MS are much stronger in the enterprise now. I'd like to see how a WCF service can be called from web server xyz, rather than just IIS. I'm not asking for all web servers to be covered (that would be duplication) but just some general guidelines.

IPSec. Several sections of the guidance sugest setting up IPSec for security. This just doesn't happen (usually) in ver secure environments. There are too many technical and beaurocratic reasons why you won't get this sort of connection set up when requested. For instance, many large organisations are moving toward application layer security as the hardware encryption accelerators just can't keep up with WAN traffic.

ASP.Net membership providers. They're a good suggestion, but they're not as useful in the enterprise as one might imagine. Generally, one would provide a heirarchy of roles and permissions within the application, and the roles would map to groups within the enterprise. The Asp.Net providers only allow the user to role mapping, which can lead to spaghetti code after a few releases (if user.isinrole("Manager") or user.isinrole("External") or user.isinrole("Support") etc. for each programmatic role check).

Then again, that's what MVPs like myself are for, isn't it? I humbly aim to fill in the gaps in some future presentations.