DarksideCookie

As some of you might have noticed, I really like OWIN. I like the simplicity, and the extremely powerful things that you can do with it in a simple way. And the fact that I don’t have to create an IHttpModule implementation, and figure out the ASP.NET event to hook into, like I had to to do the same thing before OWIN.

Katana, Microsoft’s implementation of OWIN, also offers a standardized way to handle authentication. And it is really easy to use, and not too hard to extend to work with your own identity providers. However, being me, I want to know how it works “under the hood”, and not just read a “how to build an authentication middlware” blog post…

Remember, knowing how things work “under the hood”, or “under the bonnet” if you speak the Queens English, makes it possible to do more things than just use it. By knowing how a combustion engine works (under the hood/bonnet of your car), makes it possible to add a turbo or two to it, or a compressor, or at maybe tweak the fuel consumption and horse power you get from it. But let’s leave the car analogies and look at Katana authentication middleware.

More...

In my previous post, I showed how to do a simple configuration of WS-Federation using WIF, or whatever it is called now that it is part of the framework, to enable federated authentication in ASP.NET. Something that was previously done using a tool, but now either has to be done at the start of the application, or manually.

But what about OWIN? As all new security stuff is moving to OWIN, how do we get it to work there? Well, by default, it is ridiculously simple. And that has been the whole goal with this new model.

More...

In my previous post, I walked through how “easily” one can take advantage of claims based authentication in ASP.NET. In that post, I switched out the good old forms authentication stuff for the new FedAuth stuff. In this post, I want to take it a step further and actually federate my security, but instead of just using the Windows Azure ACS’s built in identity providers, I want to build a very simple one of my own.

A lot of the solution is based on the STS project that we could get by using VS2010 and the WIF SDK. However, this project was a Web Site project using Web Forms, and I really wanted a MVC version for different reasons.

If you are fine with using VS2010 and the WIF SDK, adding a custom STS is really easy. Just create a new web project, right-click the project and choose “Add STS Reference…” and then, walking through the wizard, there will be a step that offers you to select an STS. In this step, you choose “Create a new STS project…”, which will generate a custom STS project that you can modify to your needs. Unfortunately, that option isn’t available in VS2012. Using the “Identity and Access” add-on, you are only allowed to connect to an existing STS, the ACS or a local test STS, not an STS project.

More...

Lately I have done a bit of work with claims-based identities. Most of it has been about doing federated security using the Windows Azure Access Control Service. However, I have also been working with a client that wanted claims-based identity management without federating it. For the moment, they just want to run locally, but they want to be prepared for a future where they might expand and move to a federated paradigm. And also, the way that they handle multitenancy is a perfect fit for claims…

Interestingly enough, working through their scenario, I found that there is a lot of information on the web about how to set up claims-based identity management using federation, but there is not a whole lot around for running it locally… It might not be that surprising considering that federated security has some really good points. Having been faced with this lack of information, I had to come up with a solution on my own, and building on what I built for them, I decided to create an extended example…

More...

In my previous post about Mobile Services, I talked about how to get started with the service. I also promised that I would follow up with a post about how to authenticate the users, so that is what this post is going to be about.

You currently have 4 different options when it comes to authentication, Microsoft ID (previously Live ID), Facebook, Twitter and Google. They are all 3rd party services, and requires your users to have accounts with one of the providers. Luckily, most users already do. And the neat thing about using 3rd party authentication is that you don’t have to care about handling sensitive data such as usernames and passwords. And leaving that to someone else is making your life a lot less complicated. Not to mention that having Mobile Services handle all of the actual interaction with them makes your life ridiculously simple, as you will see.

More...

I believe it is time for a really heavy blog post, and if you have ever read one of my other blog posts you are probably getting scared now. My posts are normally big, but this might actually be even bigger… Sorry! But it is an interesting topic with many things cover…

But before we can start looking at code, there are 2 things I want to do. First of all, I want to thank my colleague Robert Folkesson (warning, blog in Swedish) for getting me interested in this topic, and for showing me a great introduction.

And secondly, I want to give a quick run-through of what federated security and claims based authentication means…

Federated security means that an application relies on someone else to handle user authentication, for example Windows Live or Facebook. These identity providers are responsible for authenticating the user, and returning a token to the application, which the application can use to perform authorization.

More...

Putting applications in the cloud is great, and offers a lot of benefits (as well as some complications). We get great scalability, elasticity, low cost of ownership etc. One problem however, is that the cloud is very public. I guess this isn’t a problem in most cases, but if what you are putting up there is supposed to be secret, or at least needs to limit who gets to use it, it becomes an issue.

I am currently working on a project like this. I am not going to talk about the project as such as it is under NDA, but the fact that it is is a service in the cloud that should only be used by certain clients is not uncommon.

The service has a front end that consists of WCF services, hosted in a web role, which is what we need to secure. The worker roles behind the web roles are by default secure as they do not communicate with the outside world at all.

More...