Windows Phone 7 Developer Launch - Learn More
kick it on DotNetKicks.com   Shout it  

Building a Single Sign On Provider Using ASP.NET and WCF: Part 1

This is the first in a 4 part series on building a single sign on provider using the ASP.NET platform (ASP.NET and WCF). Originally, I wrote the article as a single post but it was pretty long, even for me.

Part 1 addresses the problem in general and how I decided to architect it.

Part 2 discusses setting up FormsAuthentication for WCF

Part 3 discusses JSONP communication between the client and WCF

Part 4 describes the implementation details and includes the source code.

Part 1: Planning an SSO Solution

We're using a custom FormsAuthentication provider and I was asked last week to integrate single sign on into our application. Since we don't have a single sign on service I had to build one from scratch. I found a few solutions I thought would work, but I had erroneously assumed that the applications would all live on the same domain. I figured we'd place each application in a separate sub-domain, until I was told that there was no guarantee the applications using my SSO solution would live under the same domain.

Architecture

I dug around and considered the two public SSO solutions I am most familiar with: Google's and Microsoft LiveID. Here's what I came up with as a result:

SSOFlowDiagram_thumb2

Guess what? I can hear you laughing from here. Disclaimer: I suck at Visio.

Here's a description of what you're seeing:

  • Client – a web browser attempting to access a web application which has been secured by a trusted SSO service.
  • Application – a web application which delegates the validation of user credentials to a centralized authentication service.
  • SSO Service – a centralized repository of user credentials and (potentially) profile data managed by a trusted 3rd party.

The SSO service has no UI whatsoever. All communication between the client and SSO service is done via cross-domain ajax calls (JSONP). While this is no requirement of SSO in general, the requirement given to me was that the client would not leave the application they were attempting to access. The benefit here is that each application retains control over the look and feel of all pages viewed by the client.

Here's how the process flows:

  1. When an unauthenticated client requests a secured resource from the application that client is redirected to an authentication page.
  2. The authentication page makes a request (via JSONP) to the SSO service for a token which can then be presented to the application as evidence of the client's identity with the SSO service.
  3. If the client has already authenticated with the SSO service and has an active session then skip to step #7 otherwise the request is denied.
  4. An unauthenticated client (SSO authentication) is redirected to a login page where the client then submits credentials for the SSO service.
  5. Upon submitting a valid set of credentials to the SSO service the client receives a cookie containing a token which is valid for the SSO service.
  6. Now that the client has successfully authenticated with the SSO service the client is redirected back to the application's authentication page (step #2).
  7. The client receives an encrypted copy of the authentication ticket from the SSO service which it can then submit to the application. NOTE: This extra step is required when cookies are set to “HttpOnly = true” because they cannot be accessed via client script (javascript).
  8. The client now submits the SSO token to the application. The application verifies the token with the SSO service by forwarding it and asking if it is a valid token.
  9. The SSO service responds to the application with a flag indicating wither or not the submitted token is valid or not. Potentially, the SSO service could also provide additional information regarding the identity of the client. If the token was valid, the application then responds to the client with a token of it's own which identifies the client to the application.
  10. The client, now authenticated with both the SSO service as well as the application, resubmits the request for the resource from step #1.

Security

Messages over JSONP are not considered secure, so at the very least you will want to make sure and use SSL to protect communication with the SSO service.

Also, EVAL is called on the JSONP response to execute the callback returned by the service. If the service is vulnerable to injection attacks and the scripts injected into the service are returned somehow via JSONP then those scripts will be executed on the client.

There are security issues you should consider when using JSONP or any type of cross-domain communication.

Conclusion

There are those among you who would be able to implement the entire solution on your own at this point – none of this is cutting edge. Stay tuned for the next installment on setting up FormsAuthentication with WCF.


Feedback

# 

Gravatar Technology is AMAZING! The fact that you were able to hear me laughing from where you are is astounding, to say the least.

I gotta tell my wife and kids about this!

;) 7/2/2009 8:04 AM | noreply@blogger.com (JasonBunting)

# 

Gravatar Is there anyway to get a copy of this in a pdf, as for the life of me I can't get this to print where it looks good.

If all else fails I am going to have to use Microsoft One Note on the thing. 7/16/2009 4:03 PM | noreply@blogger.com (Idaho House - Herb)

# 

Gravatar I'll check it out tomorrow and get back to you. I wrote it using LiveWriter, there must be a way to get fidelity but I'm on my way out today. 7/16/2009 4:36 PM | noreply@blogger.com (Mark J. Miller)

# 

Gravatar Here's a link to a copy of the article in Word - all I did was copy the content from LiveWriter to Word. I don't have a PDF writer license - hope this works for you:

files.getdropbox.com/u/273037/SSO%20Provider.docx 7/17/2009 8:41 AM | noreply@blogger.com (Mark J. Miller)

# re: Building a Single Sign On Provider Using ASP.NET and WCF: Part 1

Gravatar Hi Mark,
I am trying to implement this SSO solution but it gets failed with an error msg "The project file 'Z:\SSO\SSO.Application\SSO.Application.1.csproj cannot be opened.
The project type is not supported by this installation "
I am using VS 2008 SP1 3.5 framework.
Thanks
Bharat Jain 10/26/2009 4:31 AM | Bharat

# re: Building a Single Sign On Provider Using ASP.NET and WCF: Part 1

Gravatar You need ASP.NET MVC 1.0 Framework installed. You can get it here: http://www.asp.net/mvc/ 10/26/2009 11:00 AM | MarkJMiller

# re: Building a Single Sign On Provider Using ASP.NET and WCF: Part 1

Gravatar Yeah, that is a good technique and one that I have definitely started to use much more lately. It feels right and, there are no problems with ever having nested elements. 12/10/2009 3:54 AM | online poker guide and tips

# re: Building a Single Sign On Provider Using ASP.NET and WCF: Part 1

Gravatar I've been reading all four part's over and over and still have some difficulty understanding it all. This is mostly because I've never developed using mvc or jquery, just plain asp.net. Would you be able to add some pointers or an asp.net example site to the source for me to check-out?

Also how would one go about inserting this into a site that is already using membership, with as little disturbance as possible? 5/11/2010 6:51 AM | Bart Zuidgeest

Comments have been closed on this topic.
 

 

Copyright © Mark J. Miller