ASP.NET 2.0: Implementing Single Sign On (SSO) with Membership API

Posted on 6/30/2006 @ 8:44 PM in #Vanilla .NET by | Feedback | 88343 views

The membership API is awesome. No doubt about that. But I wish it had a more obvious in-built support for SSO. The only authenticate method takes in a username and password, there is no support for a token based system. Also, if you did add another method to verify against a ticketing authority - the membership API simply ignores it.

So the question is, How to do SSO using the Membership API - custom provider or otherwise.

Now ASP.NET has 3 kinds of authentication -

Passport - nobody uses it anymore, and that is SSO by definition anyway.
Windows - SSO is like a moot point here.
Forms - This is where the problem begins. So thats all I'm gonna discuss here.

Well, single sign on is almost always implemented using a central ticketing authority. The idea being similar to the concept of visiting a bar. You get a "token" stamped on the back of your hand as you walk into the bar, and then everywhere in the bar, you are recognized as "over 21".

Similarly, in a ticketing based SSO implementation, a central ticketing authority issues you a "ticket" at logon. Then you can integrate with any other system by passing the "ticket", rather than your authentication credentials. Then as long as the protected system can verify the "ticket" as being valid, you're in. Else, you're out.

Anyway, so the first thing you need to do is setup a ticket verification webservice. The idea being, anytime you successfully authenticate, you will be issued a ticket, which will ideally be a GUID, stored as cookie that expires when the user hits the CROSS button on his browser. Then you can circumvent the membership API's "Authenticate" method, by instead verifying the ticket - IF one is present.

So lets assume that the ticket is being passed as a querystring called "ssoToken". Obviously, if someone else sniffed your ticketID, then he could masquerade as you - so this approach requires some kind of encryption.

So in the Page_Load for your login.aspx page, write the following code -

protected void Page_Load(object sender, EventArgs e)

{

    string unescapedtokenID = Uri.UnescapeDataString(Request.QueryString["ReturnURL"]);

    string tokenID = ParseURL(unescapedtokenID);

 

 

    if (IsTokenValid(tokenID))

    {

        FormsAuthentication.SetAuthCookie(GetUserName(tokenID), false);

        Response.Redirect(unescapedtokenID);

    }

}

 

Basically "tokenID" is the token that was passed in as QueryString (or any other means), and IsTokenValid queries the ticketing web service to check the validity of the ticket. The ParseURL method is simply some magic to seperate out querystring peices out of the URL contained in the "ReturnURL" query string. If you're interested, the code for that looks like as below -

    private string ParseURL(string unescapedTokenID)

    {

        UriBuilder bldr = new UriBuilder("http://dummyurl" + unescapedTokenID);

        QueryStringParser coll = new QueryStringParser(bldr.Query);

        return coll["ssoToken"];

    }

 

The QueryStringParser class looks like this -

internal class QueryStringParser : System.Collections.Specialized.NameValueCollection

{

    internal QueryStringParser(string s)

    {

        if (s.Length != 0) s = s.Substring(1);

        int num1 = (s != null) ? s.Length : 0;

        for (int num2 = 0; num2 < num1; num2++)

        {

            int num3 = num2;

            int num4 = -1;

            while (num2 < num1)

            {

                char ch1 = s[num2];

                if (ch1 == '=')

                {

                    if (num4 < 0)

                    {

                        num4 = num2;

                    }

                }

                else if (ch1 == '&')

                {

                    break;

                }

                num2++;

            }

            string text1 = null;

            string text2 = null;

            if (num4 >= 0)

            {

                text1 = s.Substring(num3, num4 - num3);

                text2 = s.Substring(num4 + 1, (num2 - num4) - 1);

            }

            else

            {

                text2 = s.Substring(num3, num2 - num3);

            }

           

            base.Add(HttpUtility.UrlDecode(text1, Encoding.ASCII), HttpUtility.UrlDecode(text2, Encoding.ASCII));

 

            if ((num2 == (num1 - 1)) && (s[num2] == '&'))

            {

                base.Add(null, string.Empty);

            }

        }

    }

}

Thats it !! Put all these together, and you have at your hands SSO using Membership API.

 

Sound off but keep it civil:

Older comments..


On 3/27/2007 1:27:50 PM Fabio Galante Mans said ..
How to create the WebService?

so the first thing you need to do is setup a ticket verification webservice


On 7/17/2007 12:07:34 PM jackinthegreen said ..
"How to create the WebService?"

Yeah, any good examples of that web service that you can point to would be much appreciated, Thanks!!


On 9/25/2007 1:59:12 AM OHR said ..
Can we host a central ticketing authority on our own server, or just choose one of our application servers as the central ticketing server?

No body want to use Microsoft's server


On 9/25/2007 10:07:16 AM Sahil Malik said ..
Yes you can.


On 4/22/2008 3:17:01 AM prasad said ..
can we implement SSO for differnt web applications (asp.net apps running on IIS and Java apps running on JBoss) hosted in different servers within a corporate's intranet using this API?


On 10/22/2008 3:03:02 AM Julia said ..
If possible, could you send me sample code of web service of isTokenValid


On 5/25/2010 10:16:07 AM Henrik said ..
I'm probably stupid but what's to stop me from sniffing the encrypted sso token value and providing it back to the server verbatim. I don't need to decrypt it at all as far I figure. In a nut shell, this is what session hijacking is except you're sniffing the session id. You need SSL for this to be safe but then, there's no need for encrypting the sso token.


On 5/25/2010 12:21:15 PM Sahil Malik said ..
Henrik - Exactly, which is why I say - "if someone else sniffed your ticketID, then he could masquerade as you - so this approach requires some kind of encryption."


On 8/20/2010 5:42:14 AM Maxi said ..
Seems to me that, this approach does not support cross domain. or does it?


On 12/16/2010 1:43:06 PM Ganesh Murthy said ..
Microsoft has an excellent article on cross domain single sign-on http://msdn.microsoft.com/en-us/library/ms972971.aspx


On 1/13/2011 5:11:30 PM Aaron said ..
Can you please provide example of IsTokenValid