I was having a discussion with Eric Nelson on his blog the other day. I was having a rant about requirements, which I think is one of the most vital aspects of software today.

For instance, I've been told by a number of developers that MVC is the 'correct' way to develop a web application. However, I disagree strongly with this.

I don't doubt that Model View Controller is very useful for certain applications. It is a valid design pattern for solving certain problems.

However, it's not 'the correct' way to develop a web application. The only thing that is correct is the requirements. If you use MVC, and it either hinders achieving the requirements, or it adds nothing to those requirements, than MVC is not the correct design pattern to follow. Simple as that.

There have been similar patterns used in security that added no value. I worked on a project three years ago that used WS-Security, because it was the latest 'cool thing'. At the end of the day, it added no value, as SSL matched the security requirements more efficiently.

So, when should you use WS-Security? I wrote an article recently that is on the MSDN Developer Security page.

The article matches requirements to technologies, and has been used by various clients as I was writing it. I hope you find it useful.

The SOAP and WS-Security formats, although very verbose when compared to RESTful implementations, have a much more advanced security model. They give the ability to override the authentication used within IIS (which uses Active Directory). By moving the credentials (username and password) from the HTTP headers into the XML of the message, one can use the UserNamePasswordValidator class to implement custom authentication.

Here's an article I wrote for the Next Generation User Group giving all the technical details.

I read a post on Eric Nelon's blog regarding Developers vs the "others". Eric is justifiably annoyed that various levels of managers expect:
-developers to do the managers' job as well as his/her own
-developers have to understand the end goal just as well as the managers
-developers have to agree with what the manager says, even if the developer's argument is backed up by facts
-developers have to accept that their needs are unimportant (course, books etc.), whereas managers go on whatever courses, conferences that are necessary

I think that the meeting of minds here should be achieved by defining requirements:
-agree requirements. This will involve both development team and management agreeing the end result. Not something vague - you need concrete bulet points, even if this is Agile development
-map the project plan to these requirements, breaking it down to individual work tasks

This will mean that both sides know what to expect. If the manager wishes to alter the requirements, then the developer can easily track which tasks need to be altered, and give a justified, detailed estimation of how much more time/resources will be needed. So often, I've seen unprepared developers bullied into accepting ridiculous timelines because they're not giving the full picture.

Unfortunately, there's just too little management of requirements in many projects. I've even heard people say "we don't define requirements, because we do Agile development". This is wrong - agile is all about defining requirements. See this post.

This is particularly relevant to security. If you define security requirements early (for instance, the roles/access matrix for the app), then this becomes a milestone on your project plan that the team works towards. If you engage with the security team late, then there's no management buy-in to that requirement. When you try to introduce it, you are seen as a blocker.

Decided to Wordle my blog. Glad to see that 'security' is prominent!

Well, Fest 08 was a great success with 'Data Today, Data Tomorrow'. Loved the sessions and the usual Dave and Rich game show.

Here's a write up of the day:

http://www.nxtgenug.net/Article.aspx?ArticleID=283

and here's a shot of Dave McMahon giving a live demonstration of various yoga positions. Don't ask......

Google charts are an interesting tool for producing graphic representations of your data.. The Google Chart API returns a PNG-format image in response to a URL.

This is an extremely useful tool, and there is already more than one wrapper for the API so that you can call it from your code.

But how about the security aspects of this tool? Well, if you're worried about availaibility, you can store the resulting .png file on your own server, and provide your own resilience.

However, the confidentiality and integrity aspects are quite suspect. Only http is available, not https. This is a shame, as your business data deseerves better than this. You've provided HTTPS for your website, perhaps strong authentication and have protected your servers and database. Then you send that data unprotected across the internet.....

Also, you're at the mercy of Google for protection of the data while it's on their servers. I know all the techies are going to say "Yeah, but Google use xyz operating system and abc brand firewalls." Fine, but have they vetted the CVs of the admin staff that work on those servers? How do they dispose of the discs? How is the dev environment segregated from production?

If I was a hacker/criminal/hostile government, Google Charts would be a prime target for my attack.

I'd suggest the answer at present is to only send non-sensitive data across the internet to this service.

What's non-sensitive for your company? OK, answer the following question:

Can you print out the data on A4 paper, stand in your local shopping mall and hand it out to everyone passing? If the answer is NO, then don't use Google Charts for that data.

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.

I was fortunate enough to be invited to the IMTC this year to speak on WCF security. Had a great time, but what a busy day!

I left my home at 7am and travlled continuously until 2.30pm, when I arrived. And I was speaking at 3.15!

Thanks to the (large) audience that came to see me. I promised to put up the slides and code, so here it is.

Last month saw the launch of stacks of new Microsoft technology, so to celebrate we gave away loads of swag (Vista, VS 2008 and more!). Barry even had the foresight to set up a raffle.

To top it all, we had the fabtastic Simon Sabin speaking on SQL development. Really enjoyed hearing about all the new facets of the world's best database, and the co-ordinates tool that Simon showed us was awesome.

The usual suspects:

Barry hurling swag:

Simon Sabin speaking on SQL Server 2008:

I had to laugh. I've worked on a Unix based application recently. The service account is also granted access to log on to the application. Production support is also performed using this account.

Apparently, I've been told, this is fine. It's on a Unix server. Unix is secure.

Look, you can make any OS insecure if you want. And these guys really have tried......

It's important to segregate the accounts. That service account will have a high level of access to the database. The production support person, using that account, can now read and write to the database containing production data. What if you were a bank and this was a trading system? You've just blown all your legal and compliance responsibilities!

The service account should only be used for the application to run.

Create another account with access to the files for support.

Don't let someone log on to the application with this account.

This is called least privilege. Doesn't matter whether it's Unix, Windows or xyz operating system, the principle is absolute.