+1-888-365-2779
Try Now
More in this section

Forums / Developing with Sitefinity / Claims Auth - .ASPXAUTH cookie remains

Claims Auth - .ASPXAUTH cookie remains

8 posts, 0 answered
  1. Xian
    Xian avatar
    18 posts
    Registered:
    03 Oct 2014
    13 Jan 2015
    Link to this post

    I created a custom SecurityTokenServiceHttpHandler to handle requests for authentication through Azure Active Directory.   It works fine for most cases, but definitely gets wonky in some spots.  

    The main issue I'm having has been narroed down to the presence of .ASPXAUTH.   When SetAuthCookie is called, it's creating the FedAuth tokens and unfortunately the ASPXAUTH token as well, which I believe is used for "persist my login" via the normal case.

    The cookie itself is not cleared through SecurityManager's logout features (Logoff, DeleteAuthCookies).  

    The major side effect of not being able to kill this cookie is that a redirect loop is eventually caused by the presence of an ASPXAUTH cookie, telling the authentication end point you're OK, but having invalid FedAuth tokens.  The claims service will keep routing to the ProcessRequest, which will fall through to "normal behavior" and try to route to the return uri, where the user is unauthorized to go (Permissions set to only authenticated users), then back to claims service and so forth.   

     

    1.  Is there a way to set the auth cookie without the login persistence cookie?

    2.  Is this expected behavor?

     My logout is now:

    LogoutLink.Click += (sender, args) =>
    {
        // Meh.
        FormsAuthentication.SignOut();
     
        SecurityManager.Logout();
        SecurityManager.DeleteAuthCookies();
     
        InitializePanel(ClaimsManager.GetCurrentIdentity());
     
        // Redirect to the current URL and let Sitefinity throw it to the unauthorized page.
        Context.Response.Redirect( Context.Request.Url.AbsoluteUri, true);
    };

    Note, I now catch the case in ProcessRequest to prevent the described scenario, but again it feels heavy handed.

    public override void ProcessRequest(System.Web.HttpContext context)
            {
                // ...
     
                // If they're hitting the login service after the system considers them auth'd, log them out.  There's a
                // real solid chance that the claims aren't properly aligned and the user is going to be redirected infinitely.
                if (context.User.Identity.IsAuthenticated)
                {
                    SecurityManager.Logout();
                    SecurityManager.DeleteAuthCookies();
                }
     
     
                if (!String.IsNullOrWhiteSpace(context.Request.QueryString["code"]))
                {
                    // Do secure AAD token grabbin'.
     
                    // Redirect back to the claims service, which will mark the user as authenticated and route to the return URI.
                    RedirectToClaimsService(context);
                    }
                }
     
                base.ProcessRequest(context);
            }

     

     

     

     

  2. Patrick
    Patrick avatar
    18 posts
    Registered:
    31 Mar 2015
    25 Apr 2015
    Link to this post

    Hello Xian. Were you able to resolve the issue with the redirect loop?

    I am facing a similar issue where I configured my ​SF app to use an external STS. I am seeing a redirect loop after the STS authenticates the user, generates the security token, and then redirects user back to the SF app: At this point the SF app does allow the user in but instead sends another request to the STS. And there the endless redirect loop begins.

  3. Patrick
    Patrick avatar
    18 posts
    Registered:
    31 Mar 2015
    25 Apr 2015 in reply to Patrick
    Link to this post
    Hi Xian. I want to experiment with your workaround: can you give me details on how to override the ProcessRequest method ​shown in your example code? I assume ​it's somewhere in login code of the SF app. Note that I'm new to Sitefinity.
  4. Xian
    Xian avatar
    18 posts
    Registered:
    03 Oct 2014
    25 Apr 2015
    Link to this post

    My final solution was not much different than what you see above.  Inside the block where I have captured a successful authentication, I set the current user via something like this:

     

    var currentUser = UserUtil.GetUserByAzureId(objectId);
    if (currentUser != null)
    {
        var vals = context.Request.RequestContext.RouteData.Values;
        var service = ((string)vals["Service"]).ToLower();
     
        SetAuthCookie(currentUser);
        var reqMessage = RequestMessage.Empty;
        SendToken(context, currentUser, reqMessage, service);
     
        // This stores the ObjectId from the successful claim or auth code retrieval.
        AzureRequestManager.ObjectIdentifier = null;
     
        RedirectToService(context);
    }

     

    Redirect to service looks like:

    private static void RedirectToService(HttpContext context)
    {
        const string ServiceUrl = "~/" + Constants.LocalService + "/SWT";
        var serviceUrl = ServiceUrl + (!ServiceUrl.Contains("?") ? "?" : "&");
     
        var realm = context.Server.UrlEncode(context.Request.Url.GetLeftPart(UriPartial.Authority));
        serviceUrl = serviceUrl + "realm=" + realm + "&redirect_uri=" + context.Server.UrlEncode(PageUtil.GetHomePageUrl()) + "&redirect_url_failure=" + context.Server.UrlEncode(context.Request.Url.AbsoluteUri);
        context.Response.Redirect(serviceUrl);
    }

     

    If you've set your token and auth cookie, the next time you direct your request to the service, it'll register the claim properly.

     

  5. Xian
    Xian avatar
    18 posts
    Registered:
    03 Oct 2014
    25 Apr 2015
    Link to this post

    Also worth noting, the Logout code above is about the same as well, barring some different redirects.

     

  6. Patrick
    Patrick avatar
    18 posts
    Registered:
    31 Mar 2015
    25 Apr 2015 in reply to Xian
    Link to this post
    Thx Xian! I want to experiment with your workaround: Can you give me details on how/where to override the ProcessRequest method ​shown in your example code? I assume ​it's somewhere in login code of the SF app. Note that I'm new to Sitefinity.
  7. Patrick
    Patrick avatar
    18 posts
    Registered:
    31 Mar 2015
    25 Apr 2015
    Link to this post

    Hi Xian.

    Here's a concrete example: I'm experimenting with the following SF app from the SF SDK https://github.com/Sitefinity-SDK/Telerik.Sitefinity.Samples.Quantum

    I was able to configure this app to use my external STS. Currently the flow is as follows:

    User --> SF app --> User logs in with username/pwd --> ​User clicks submit, is redirected to My STS -->  My STS generates token --> Redirect back to SF app --> User is logged in

    I want to tweak the SF app some more so the follows becomes:

    User --> SF app --> ​User is redirected to My STS -->  My STS generates token --> Redirect back to SF app --> User is logged in

    Can you help me figure out the tweaks needed in this SF app? I think it may be as simple as modifying the Login widget.
  8. Xian
    Xian avatar
    18 posts
    Registered:
    03 Oct 2014
    27 Apr 2015
    Link to this post

    The way to accomplish the hook is all described in here: https://github.com/Sitefinity/Sitefinity-External-STS-Integration

     I'd suggest setting up this code as outlined in the readme and stepping through it to get comfortable.  

    I am under NDA for a few aspects of the authentication that will go any deeper than this, so I'd just urge you to review the sample.

8 posts, 0 answered