In this blog series I have been discussing a simple way any organization of any size can put into place a Single Sign On solution. In the first part I discussed, at very high level, Windows Identity Foundation (or WIF); which has been provided by Microsoft as a simple way of implementing claims-based authentication. If you haven’t read the first part I suggest you go back and read that one first. It will give you a basic understanding of WIF before reading this next part where I will be discussing WIF in practice.
In my conclusion of part one I stated that WIF provides a foundation (as it’s name implies) for claims-based authentication but in and of itself does not provide any implementation. This is done on purpose because Microsoft is trying to give the development community a framework for creating their own implementations of WIF. That may be great for organizations that can afford to pay developers to spin their own WIF implementation but many small and medium sized companies just don’t have the time or resources to do this. Fret not! Luckily for us the guys at ThinkTecture have done all of the hard work and have provided a turnkey solution called IdentityServer that not only implements WIF but also incorporates the mechanisms for Single Sign On.
Let me be clear up front, neither I nor my organization are in any way affiliated with ThinkTecture but we are fans of their IdentityServer product. I think after reading what their IdentityServer product has to offer you may be as well.
At its core IdentityServer is a light-weight security token service built using .NET 4.5, ASP.NET MVC4, WCF and Web API. It has out-of-the-box support for user management using the ASP.NET membership and roles provider, but provides extensibility points to integrate arbitrary user databases. Furthermore almost any aspect of token issuance and data management can be customized using a plugin model. More information and source code, yes I said source code, can be found here. To be honest their website and documentation doesn’t do justice to the power and impact IdentityServer can have on your organization – especially with regards to SSO and flexibility on how you authenticate your users. To save you some time in reading their website, let’s discuss how it can be used in your organization and how it can provide you a simple SSO solution.
First and foremost, IdentityServer is a standalone website you can either install within your organization or host out in the cloud. It has a management interface you can use to configure general server information, certificates, protocols, identity providers, and much more. While you don’t need to be an expert in WIF and security concepts, it is helpful to at least understand some basics. The admin interface provides some inline help but I have found sometimes the need to occasionally do additional research to understand the setting options a bit more.
Referring back to my previous post and the discussion of WIF, the Identity Server is going to, at a minimum, play the role of a Security Token Service (STS). What this means is your application(s) are going to rely on the IdentityServer for collecting credentials and subsequently issuing a claims-based authentication token. Your applications can then use these tokens to identity the authenticated user. This takes the responsibility of authenticating users away from your applications and puts it on the IdentityServer.
With IdentityServer you have a couple of options when it comes to collecting and issuing these claims-based authentication tokens: 1) using IdentityServer’s built in authentication or 2) redirecting to a trusted Identity Provider (IdP).
In the first option, when your applications redirect to the IdentityServer for authentication, the users will be presented with a login page hosted in the IdentityServer and will use the credentials managed within IdentityServer itself. In this scenario you are using IdentityServer as a STS and is the simplest to configure of the two options because it comes pre-configured this way.
The second option is a recent addition to IdentityServer and allows you to redirect your users to a trusted Identity Provider such as Google, Microsoft Live, Twitter, Facebook, etc. In this setup your IdentityServer is actually playing two WIF roles, 1) it is acting as the STS to your applications and 2) it is also acting as a Relying Party (RP) because it is “relying” on an Identity Provider (which is acting as a STS for your IdentityServer) for authentication tokens.
There are a couple things you have to keep in mind when going the Identity Provider route. First, the Identity Providers you use to authenticate with will probably need to be configured on their end to accept requests from your IdentityServer for authentication. This will include how that Identity Provider should redirect back to your IdentityServer. Second, you will need to configure the Identity Provider in your IdentityServer with the necessary information for IdentityServer to talk with the Identity Provider. Configuring your IdentityServer to use Identity Providers is not hard but it does require a bit more knowledge of how to talk with Identity Providers.
If you have the situation/need/desire to allow your users to choose an Identity Provider from two or more Identity Providers (which many sites are doing these days), then IdentityServer has you covered on that front as well with its Home Realm concept. In this setup when IdentityServer receives a request from your applications for an authentication token instead of being presented with an Identity Provider’s login screen they will be presented a Identity Provider selection screen where the user will choose the provider they wish to log in with.
So, for example say you wanted to allow your users to use Google, Facebook, or ADFS to log into your application; with IdentityServer you can do this by configuring an Identity Provider for Google, Facebook, and ADFS on your IdentityServer. Then, when your users are redirected to you IdentityServer for authentication, they will first see a screen where they would choose either Google, Facebook, or ADFS and once doing so will be redirected to the login page for the Identity Provider they chose.
I wish I could go through all of the different options and configurations of IdentityServer but perhaps that can be for another day. Right now I wanted to touch on some of the basic but cool features provided by this product. If you decide you would like to use IdentityServer but need help installing or configuring it please feel free to contact me.
Now that we have discussed the concepts in WIF and seen a simple solution for implementing a STS, the next part to this series will be discussing how to set up your Relying Party applications. If you would like to be notified when the next part of this series is published just follow me (@mpyost) or my company (@yosttechies) on Twitter. As always, if there are any comments or questions feel free to post them to this blog entry or send them to me via email.
Wednesday, September 4, 2013
Monday, August 26, 2013
Single Sign On Made Simple: Part 1-WIF
Almost every organization I have ever worked at, with, or for has discussed and dreamed about implementing a Single Sign On (SSO) solution for either some or all of their applications and/or websites. It is a very interesting and enticing prospect to be able to enable your users to enter one username and password in order to access multiple applications. I am not going to take the time to explain SSO any more than that but if you are not familiar with SSO or would like to learn more about it there is a plethora of blogs and articles on the internet that should help get you up to speed.
In this series of blog articles I am going to go over a way I have found to very quickly and easily implement a SSO solution - without writing a lick of code! But I won’t stop there; the solution I will suggest will also enable your organization to authenticate your users via one or more of the many well known identity providers out there such as Active Directory Federated Services, Google, Live, Facebook, and more – or you can roll your own if so inclined. Finally I will take this SSO solution and extend it to your Windows based applications as well.
In this first part I am going to introduce you to the underlying framework that will be doing most of the work. While I don’t expect you to understand everything about this framework, I do want to point out its existence and role in our solution. If you are developer or you are at an organization that is going to want to write their own identity provider then you are going to want to know about the framework.
At the center of our solution is Microsoft’s Windows Identity Foundation (WIF). Until recently it was an add on framework but starting with .NET Framework 4.5, WIF has been fully integrated into the .NET framework. At it’s core WIF is a framework for building identity-aware applications; it abstracts the WS-Trust and WS-Federation protocols and presents developers with APIs for building security token services and claims-aware applications. I won’t go into too much detail about the framework but I do want to point out the major parts of the framework because when I get to my solution for SSO you will need to have a basic understanding to appreciate what it does for you.
I do want to point out that WIF is based on a concept called the Claims-Based Identity Model which simply means that a user in your applications is presented as a set of claims. One claim could be the user’s name, others might be their email address or display name. The basic idea is your application will be given a set of data an external identity system is configured to provide about the user – along with cryptographic assurance the identity data you receive comes from a trusted source, of course. [1]
A basic WIF scenario usually consists of one or more Relying Party (RP) applications and a Security Token Service (STS). The Relying Party (RP) is basically an application that relies on claims issued by a STS. An RP is also often called a “claims aware application” or “claims-based application.” The Security Token Service (STS) is the service that builds, signs, and issues security tokens according to the WS-Trust and WS-Federation protocols. The STS will be the one responsible for collecting and validating user credentials and if successful, returning to the RP a claims-based token representing the user. [2,3] If you are confused don’t worry, the solution I propose should help make this abstract concept a little more concrete.
Microsoft’s Windows Identity Foundation is a great start but it doesn’t give us anything to immediately get up and running – let alone a SSO solution. It is as it’s name implies – a foundation, not a solution. Continue to part 2 of this blog series to be introduced to a solution I have discovered that makes implementing WIF and SSO a snap and all without writing a single line of code. I welcome your comments and feedback on this first part. Also you may contact me via the “Contact Us” page at http://www.yosttechnologies.com/contact.
References:
1. The Claims-Based Identity Model (http://msdn.microsoft.com/en-us/library/ee517291.aspx)
2. Relying Party (http://msdn.microsoft.com/en-us/library/ee748466.aspx)
3. Security Token Service (http://msdn.microsoft.com/en-us/library/ee748490.aspx)
In this series of blog articles I am going to go over a way I have found to very quickly and easily implement a SSO solution - without writing a lick of code! But I won’t stop there; the solution I will suggest will also enable your organization to authenticate your users via one or more of the many well known identity providers out there such as Active Directory Federated Services, Google, Live, Facebook, and more – or you can roll your own if so inclined. Finally I will take this SSO solution and extend it to your Windows based applications as well.
In this first part I am going to introduce you to the underlying framework that will be doing most of the work. While I don’t expect you to understand everything about this framework, I do want to point out its existence and role in our solution. If you are developer or you are at an organization that is going to want to write their own identity provider then you are going to want to know about the framework.
At the center of our solution is Microsoft’s Windows Identity Foundation (WIF). Until recently it was an add on framework but starting with .NET Framework 4.5, WIF has been fully integrated into the .NET framework. At it’s core WIF is a framework for building identity-aware applications; it abstracts the WS-Trust and WS-Federation protocols and presents developers with APIs for building security token services and claims-aware applications. I won’t go into too much detail about the framework but I do want to point out the major parts of the framework because when I get to my solution for SSO you will need to have a basic understanding to appreciate what it does for you.
I do want to point out that WIF is based on a concept called the Claims-Based Identity Model which simply means that a user in your applications is presented as a set of claims. One claim could be the user’s name, others might be their email address or display name. The basic idea is your application will be given a set of data an external identity system is configured to provide about the user – along with cryptographic assurance the identity data you receive comes from a trusted source, of course. [1]
A basic WIF scenario usually consists of one or more Relying Party (RP) applications and a Security Token Service (STS). The Relying Party (RP) is basically an application that relies on claims issued by a STS. An RP is also often called a “claims aware application” or “claims-based application.” The Security Token Service (STS) is the service that builds, signs, and issues security tokens according to the WS-Trust and WS-Federation protocols. The STS will be the one responsible for collecting and validating user credentials and if successful, returning to the RP a claims-based token representing the user. [2,3] If you are confused don’t worry, the solution I propose should help make this abstract concept a little more concrete.
Microsoft’s Windows Identity Foundation is a great start but it doesn’t give us anything to immediately get up and running – let alone a SSO solution. It is as it’s name implies – a foundation, not a solution. Continue to part 2 of this blog series to be introduced to a solution I have discovered that makes implementing WIF and SSO a snap and all without writing a single line of code. I welcome your comments and feedback on this first part. Also you may contact me via the “Contact Us” page at http://www.yosttechnologies.com/contact.
References:
1. The Claims-Based Identity Model (http://msdn.microsoft.com/en-us/library/ee517291.aspx)
2. Relying Party (http://msdn.microsoft.com/en-us/library/ee748466.aspx)
3. Security Token Service (http://msdn.microsoft.com/en-us/library/ee748490.aspx)
Thursday, August 22, 2013
WebAPI, NServiceBus, and SignalR, Oh My!!
I just recently got done helping prove out a very interesting concept that I thought I would share. This may not be anything new for some of you but for many this may be a very eye opening concept. It has to do with how you can combine three technologies to give you a very resilient and “push event” driven RESTful API for your applications and/or customers to use.
A technology many of us already know and love is Microsoft’s WebAPI framework that comes built into their ASP.NET MVC framework. It enables developers to very quickly build truly RESTful APIs that by default use JSON for the data messages. I have been using this platform ever since it was in pre-release and if you are in the process of evaluating your options for building an API – this is the one to look at. More information about it can be found at http://www.asp.net/web-api.
Now, this is only part of the picture and I have said nothing earth shattering so let's get on to the good stuff.
So lets say you or your organization/team has spent the time to build your API on the WebAPI platform and everything is going great but now you have come to the point where you need your services to talk to each other. Do the services call each other? Well that doesn't feel right. Plus, how do I know when one of the services does something that another service needs to respond to as well? Do I use SQL data triggers? Ick!! Enter NServiceBus by Particular Software (http://particular.net/NServiceBus).
As it’s name implies, it is at its core a service bus that can be used to distribute events and messages between various listeners. It enables you to decouple your services to achieve a true SOA (service oriented architecture) but maintains a transactional consistency, reliability, and scalability you will need. This means your services can subscribe to events other services publish. Ok, a bit tough to follow so lets look at an example.
Say for simplicity sake you have two WebAPI services; a Inventory API and and a Products API. Now, lets say your Products API needs to know when the Inventory API changes available inventory so it can update the “availability” information on its products. This can be easily achieved by the Inventory API publishing a “InventoryUpdate” event to NServiceBus which then puts it in its queue and broadcasts the event to all subscribers of that event. For the ProductsAPI to get this event it simply subscribes to the “InventoryUpdate” event. Bam! You have “connected” your services together with NServiceBus.
So, thanks to NServiceBus your services are “talking” to each other via events but that is really only part of the picture. Wouldn’t it be nice if you could take those events and pass them on to the consumers of your APIs? But wait, we are talking about a WEB API so how can this be done? Enter SignalR.
Only until recently it was just wishful thinking of API builders to be able to push notifications to consumers of their APIs. Now, thanks to a new framework put out by Microsoft called ASP.NET SignalR these dreams have coming true. Essentially ASP.NET SignalR is a library that makes it incredibly simple to “push” events over the HTTP protocol. Without going into too much detail, SignalR uses HTTP web sockets to push in real time data to a website. More information about the framework and how to use it can be found at http://signalr.net/.
So how does this apply to WebAPI you ask?
Well, since your WebAPI is really just a website it can use SignalR to push events to your API consumers so they get real time notifications. In the past your API consumers would need some kind of “heartbeat” that constantly called your API for status updates to determine if an event occurred but with SignalR they will be notified immediately via “events” your API pushes out. Whether the consumer of your API is another website or application it can attach event handlers to these push notifications – essentially closing the loop on service events.
While all of this may seem very confusing and complicated, for what is being achieved it is actually very simple and elegant. This approach allows you to develop a very distributed API while maintaining interconnectivity between each of your services and their consumers. I can almost guarantee you we are going to see more and more need for this type workflow and with WebAPI, NServiceBus, and SignalR, there is no reason you can’t do it now.
Feel free to leave me comments or feedback. If you have specific questions about this post please contact me at matt@yosttechnologies.com or go to our website at http://www.yosttechnologies.com and submit your comments.
A technology many of us already know and love is Microsoft’s WebAPI framework that comes built into their ASP.NET MVC framework. It enables developers to very quickly build truly RESTful APIs that by default use JSON for the data messages. I have been using this platform ever since it was in pre-release and if you are in the process of evaluating your options for building an API – this is the one to look at. More information about it can be found at http://www.asp.net/web-api.
Now, this is only part of the picture and I have said nothing earth shattering so let's get on to the good stuff.
So lets say you or your organization/team has spent the time to build your API on the WebAPI platform and everything is going great but now you have come to the point where you need your services to talk to each other. Do the services call each other? Well that doesn't feel right. Plus, how do I know when one of the services does something that another service needs to respond to as well? Do I use SQL data triggers? Ick!! Enter NServiceBus by Particular Software (http://particular.net/NServiceBus).
As it’s name implies, it is at its core a service bus that can be used to distribute events and messages between various listeners. It enables you to decouple your services to achieve a true SOA (service oriented architecture) but maintains a transactional consistency, reliability, and scalability you will need. This means your services can subscribe to events other services publish. Ok, a bit tough to follow so lets look at an example.
Say for simplicity sake you have two WebAPI services; a Inventory API and and a Products API. Now, lets say your Products API needs to know when the Inventory API changes available inventory so it can update the “availability” information on its products. This can be easily achieved by the Inventory API publishing a “InventoryUpdate” event to NServiceBus which then puts it in its queue and broadcasts the event to all subscribers of that event. For the ProductsAPI to get this event it simply subscribes to the “InventoryUpdate” event. Bam! You have “connected” your services together with NServiceBus.
So, thanks to NServiceBus your services are “talking” to each other via events but that is really only part of the picture. Wouldn’t it be nice if you could take those events and pass them on to the consumers of your APIs? But wait, we are talking about a WEB API so how can this be done? Enter SignalR.
Only until recently it was just wishful thinking of API builders to be able to push notifications to consumers of their APIs. Now, thanks to a new framework put out by Microsoft called ASP.NET SignalR these dreams have coming true. Essentially ASP.NET SignalR is a library that makes it incredibly simple to “push” events over the HTTP protocol. Without going into too much detail, SignalR uses HTTP web sockets to push in real time data to a website. More information about the framework and how to use it can be found at http://signalr.net/.
So how does this apply to WebAPI you ask?
Well, since your WebAPI is really just a website it can use SignalR to push events to your API consumers so they get real time notifications. In the past your API consumers would need some kind of “heartbeat” that constantly called your API for status updates to determine if an event occurred but with SignalR they will be notified immediately via “events” your API pushes out. Whether the consumer of your API is another website or application it can attach event handlers to these push notifications – essentially closing the loop on service events.
While all of this may seem very confusing and complicated, for what is being achieved it is actually very simple and elegant. This approach allows you to develop a very distributed API while maintaining interconnectivity between each of your services and their consumers. I can almost guarantee you we are going to see more and more need for this type workflow and with WebAPI, NServiceBus, and SignalR, there is no reason you can’t do it now.
Feel free to leave me comments or feedback. If you have specific questions about this post please contact me at matt@yosttechnologies.com or go to our website at http://www.yosttechnologies.com and submit your comments.
Subscribe to:
Posts (Atom)