Federated SignIn Requires Federated SignOut

Posted on Updated on

Using WIF and a Passive STS is cool, but it’s even cooler when your Passive STS is in a different machine.

Now that we have Federation SignIn and a Passive STS that lives in a Different box and all out web apps rely on that external STS… How can I sign out?

In my case I tried everything and of course, it worked in my machine. Then it got deployed and the user didn’t get signed out because the browser didn’t expire the WIF token.

I executed all this and custom code to make the cookies expire but there was one left, the one created by the STS.

FederatedAuthentication.SessionAuthenticationModule.SignOut();
FederatedAuthentication.SessionAuthenticationModule.DeleteSessionTokenCookie();
FederatedAuthentication.WSFederationAuthenticationModule.SignOut(false);
FormsAuthentication.SignOut();

Bloody cookie, die!!! But nothing. The browser wouldn’t expire it and then it all made sense, I can’t make expire cookies that I haven’t created myself. So I thought that there would be a solution to this and I run all this without any luck. I checked the WIF doco, I Goggled it with Bing and nothing.

Finally I found a reference to something and of course NO SAMPLES (Isn’t WIF wonderfull!!!)

The solution is using the FederatedSignOut method that redirects to the STS, this one signs you out and redirects the browser to the page that you wanted to go to let the user know that he’s out.

WSFederationAuthenticationModule authModule = FederatedAuthentication.WSFederationAuthenticationModule;
string signoutUrl = (WSFederationAuthenticationModule.GetFederationPassiveSignOutUrl(authModule.Issuer, authModule.Realm, null));
WSFederationAuthenticationModule.FederatedSignOut(new Uri(authModule.Issuer), new Uri(authModule.Realm + "LoggedOut.html"));

It’s up to you to find out how to solve the new issue, the redirection to LoggedOut.html sends you back to the Login page in the STS because you where logged out (this is good fun if you use Windows Authentication because you get logged in again without knowing it.

The second catch is… once you are in the LoggedOut.html page, press the back button in the browser🙂

Have fun

16 thoughts on “Federated SignIn Requires Federated SignOut

    anant said:
    May 5, 2010 at 16:11

    I am facing some issue here. I am using FederatedPassiveSignInStatus control. Signout works locally well. Once I deploy my RP and RP-STS on cloud user does not get loggedout. and after clicking the user come back to same RP page and remains logged in. Where should the code that you have given go? on IP-STS or on RP?

      rmencia responded:
      May 5, 2010 at 22:39

      That code goes in the Web site.
      How this works is:
      – You are in your Web site
      – User clicks on a signout button and you want to sign him out
      – You run that code (in a controller if MVC or the code behind if Web forms)
      – It generates a redirection in the Response that forces the browser to go to the STS with a ws-signout message (and with the direction you want the STS to redirect after the signout)
      – The STS signs you out and redirects to the page that you specified
      – You need to be sure that the logout page has been excluded from the security (in the web.config) or the Passive redirection will send you back to the STS for Login.

      The cookies that are involved in you being signed in are “.ASPXAUTH” + “FedAuth”+”FedAuth1″+”FedAuth2” (broken in chunks because the bootstraptoken is long).
      If your code works in locan and not when the STS is elsewhere then
      – clear all you cookies from the browser
      – login and logout in Firefox with the net trace enabled and persist enabled (to see that the redirections are correct)
      – in firefox, go to inspect the cookies and check the cookies created (who)
      – remember only the one that created the cookie can delete it (that’s why in local you can get rid of that cookie)

      I hope it helps

      Manish Yengantiwar said:
      February 18, 2011 at 15:13

      I am facing some issue here. I am using FederatedPassiveSignInStatus control.
      I am using this code on signout event of control

      if (sessionAuthenticationModule != null)
      {
      sessionAuthenticationModule.DeleteSessionTokenCookie();
      sessionAuthenticationModule.SignOut();
      }

      WSFederationAuthenticationModule authModule = FederatedAuthentication.WSFederationAuthenticationModule;
      if (authModule != null)
      {
      string signoutUrl = (WSFederationAuthenticationModule.GetFederationPassiveSignOutUrl(authModule.Issuer, authModule.Realm, null));
      WSFederationAuthenticationModule.FederatedSignOut(new Uri(signoutUrl), new Uri(authModule.Realm));

      }
      }
      Still I am getting claims after sign out

        Roberto Mencia responded:
        February 20, 2011 at 22:48

        You can try this to delete your cookie (both things):
        FederatedAuthentication.SessionAuthenticationModule.CookieHandler.Delete(); FederatedAuthentication.SessionAuthenticationModule.DeleteSessionTokenCookie();

        And then, use the redirection that I have in my sample. Please note that I’m redirecting to authModule.Issuer and not to the signoutUrl.

        In your code you tell the STS to redirect to authModule.Realm after signing out. This will automatically redirect you again to the STS, so if you use Windows Authentication, it’ll silently log you in and it’ll create the cookie again.

        Give it a try to see what happens.

    Marc S. Gibian said:
    August 7, 2010 at 01:03

    I am using FederatedSignOut and am running into a very wierd error. Depending on how I deploy my token provider, I sometimes get an “Thread was being aborted” error from FederatedSignOut. I am not doing anything fancy and am totally puzzled. Has anyone else encountered this problem and what was the resolution?

    (This is the LAST bug before a project ships so I’m getting rather desperate).

    Thank you for your help,
    Marc

      Roberto Mencia responded:
      August 8, 2010 at 22:25

      I’ve seen that before.
      When you add a default STS in your project, look in the file Default.aspx.cs in the method Page_PreRender() there is a catch that does nothing check the catch(ThreadAbortException ex). I’ve heard somewhere that it is not a problem and you can safely ignore it because it is due to the page redirect.
      If you ignore it and everything still works, then that’s your explaination (the exception has to happen in the STS!)

      I’ve found this thread in the MSDN forums talking about that, and I’m sure there are a lot more (Link)

    Varun Paval said:
    December 6, 2011 at 06:42

    I am having a different issue while deployed the above code

    it successfully logged out from the federated authentication, but it lands on an error page.

    the page’s heading is ‘Federation Error ‘

    error message is below,

    Oops…an error occurred
    Reference Number: a95c9f09-376a-4233-b985-e3502f67d108
    Application Id:
    Launch an Internet Explorer InPrivate session (Ctrl+Shift+P) and retry.

    If issue persists, click here to report this error.

    Learn more about InPrivate Browsing

    regards,

    Roberto Mencia responded:
    December 6, 2011 at 21:16

    I haven’t tested the InPrivate because our clients don’t use it, sorry.
    Everyday I find something new with WIF. To me, it looks like it is not fully baked and the documentation is scarce.
    So welcome to the “I learn something new everyday with WIF”. If you find any solution, please share it with the rest so we all can find a bit of hope in our journey.

    Bill B said:
    December 8, 2011 at 20:43

    If run into another issue related to federated sign out and shared browser session described below.
    Using WIF, WCF within a Silverlight client accessing backend WCF services. The application sign out uses Federation Authentication Module SignOut method which in turn calls Session Authentication Module (SAM) DeleteSessionTokenCookie for the local RP (Relying Party) sign out. A sign out to the the IP (Issuing Party) is subsequently called. All of this functions as expected.

    I have come across the following multiple browser scenario relating to shared session that results in a “remote server returned an error not found” issue. If IE’s “New Session” is used this is not an issue.

    Steps:
    1.Use IE shortcut to open a browser instance 1, navigate to application and login.
    2.Use IE shortcut to open a browser instance 2, navigate to application and login.
    3.Log out of application in browser instance 2.
    4.Perform any operation that requires communication to the server. e.g. Log out of application browser instance 1.

    Result: “remote server returned an error not found” exception

    Is it possible to detect that the WIF token has been deleted prior to making a WCF call in browser instance 1 and so notify the user. The IdentityModelServiceAuthorizationManager.CheckAccessCore (OperationContext) method is being used to verify service access (authorization) prior to making any WCF service calls. Would it be possible to access and evaluate session token related information at this time? Or is there another approach that can be used?

    om said:
    January 26, 2012 at 00:38

    Hi Roberto,
    Wondering if you have any idea to setup a home page on RP i.e. I want the user to land on home.aspx when they visit the site very first time.
    On the home page there is a “Login” link which if the user clicks takes them to my STS site (this is all set).
    It’s just that when I launch my RP site it directly takes to STS Login page instead of my home.aspx.

    Any thoughts?

    Thanks,
    Om

      Roberto Mencia responded:
      January 26, 2012 at 01:00

      What you need to do is add your home.aspx as an exception to WIF validation on the web.config (WIF won’t validate that page and therefore it won’t redirect to the STS).

      You will also need to add as an exception the LoggedOut.aspx if you have any, so you can redirect to that page once the STS has signed out the user.

        om said:
        January 26, 2012 at 01:03

        Thanks you for prompt reply. I have this in my location allow users=”*” for my page in web.config. Do you mean that?
        Or can you explain how to do this “add your home.aspx as an exception to WIF validation “?

        Roberto Mencia responded:
        January 26, 2012 at 01:23

        If I can remember, you need to add the section location (From the top of my head, I think that’s enough)
        There are samples in MSDN: http://msdn.microsoft.com/en-us/library/b6x6shw7%28v=vs.71%29.aspx

        The other solution is having 2 websites (one inside the other as a subfolder) and you secured app lives inside the other one.

        Sample:
        http://www.mysite.com/ ==> would have your public stuff
        http://www.mysite.com/Secure/ ==> would have your secured web site,
        So when you access your public area there is no validation (you can add all your public stuff there). As soon as you try to access your secure area the app would redirect for login.

        om said:
        January 26, 2012 at 01:29

        Yep, that’s exactly I had.I changed my search terms after reading your first response and found this: http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/71806907-393f-4782-9c30-971be94a2b62/
        Though really weird reason, I just implemented it and my initial tests shows it’s working.

        I still believe just location allow=”*” should have worked instead of removing deny=”?” as mentioned in the link.

        Thank you so much for your prompt attention.

    yaron said:
    February 8, 2012 at 14:52

    Hi, if someone found a solution to the “The second catch” please provide an answer here :
    http://stackoverflow.com/questions/9154011/azure-acs-claims-url-exposed-in-browser-history-security-hole

    Leroy said:
    July 20, 2016 at 06:25

    Im using WSFederationAuthenticationModule.FederatedSignOut it signs me out of my application takes me back to my 3rd party STS but the 3rd party STS keep’s me logged in

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s