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...
After having blogged a couple of times about how to build a simple STS, how to use claims based authentication in MVC 4.5 and how to set up federation with Azure Access Control Service, I thought it might be time to post a quick walkthrough of how to set up a simple federation with an existing STS.
Why did I think of that right now? Well, the pretty awesome “Identity and Access Tool” extension to Visual Studio has been removed from later versions of Visual Studio, making setting up federation a manual task. Unless you do it as you set up your application... And having been playing around with federation for a couple of days now in a project that wasn’t set up from scratch, I decided to just add a quick blog post on how to do a simple set up with the least amount of effort.
More...
Recently I decided that I wanted to see how easy it would be to build a Windows 8 application that consumed the Windows Azure Management API. It seemed like it should be an easy thing, and something that could potentially end up in a nice management/overview/dashboard kind of application. However, it isn’t quite that simple as I thought as Windows Azure uses certificates for authentication of the HTTP requests being used.
Using certificates for HTTP requests isn’t really that hard, at least not when working in .NET. But in Windows 8 apps, we are using WinRT, which is way more sandboxed, and to be honest, a bit more complicated, which makes it a little bit more complex…
More...
I recently ran into a problem where the application I was working on didn’t pass the security information as expected to the server. The application in this case is a Silverlight client, with a WebAPI and SignalR backend. For security, we are using WIF…or federated security…I don’t know what to call it anymore. We aren’t really federating it today, but it is based on the same framework…
It has been a while since I was involved in the system, but I got roped back in to solve some issues. And while doing so, I discovered that I wouldn’t get a proper security context for calls made from the client to the server using SignalR. For some reason, those calls where just not being authenticated properly…
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...
A week ago I ran into Alan Smith at the Stockholm Cental Station on the way to the Scandinavian Developer Conference. We were both doing talks about Windows Azure, and we started talking about different Windows Azure features and thoughts. At some point, Alan mentioned that he had heard a few people say that they would like to have their BrokeredMessages encrypted. For some reason this stuck with me, and I decided to give it a try…
My first thought was to enherit the BrokeredMessage class, and introduce encryption like that. Basically pass in an encryption startegy in the constructor, and handle all encryption and decryption inside this subclass. However, about 2 seconds in to my attempt, I realized that the BrokeredMessage class was sealed. An annoying, but somewhat understandable decision made by Microsoft. Ok, so I couldn’t inherit the class, what can you do then? Well, there is no way to stop me from creating a couple of extension methods…
More...
In my previous post I gave a semi-quick introduction to NancyFx. This time, I want to take Nancy and combine it with Azure ACS. Not a very complicated thing as such, but still something I want to do as I enjoy working with both technologies.
Just as in the last post, I will self-host Nancy in a console application, and use NuGet to get it going. I will also re-use the “www.nancytesting.org” domain I set up in my hosts file in the last post.
Once I got my console application going with a host, and an empty NancyModule, it is time to start looking at the ACS.
More...
Sorry, for the cryptic title for this post, but it is sort of true, at least when it comes to client access policies. And I didn’t know it until a couple of days ago…
As a part of a project I am working on, we are deploying an STS (Secure Token Service) to handle authentication the users of an OOB Silverlight application. The STS is completely decoupled from the application, as it should be, and is hosted on its own, and the client requests a token from the service through a simple HTTP GET with basic authentication.
More...
8. November 2011
ZeroKoll
Azure , Security
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...