locked
ID3206: A signin response may only redirect within the current web application: (url) is not allowed RRS feed

  • Question

  • I have seen other posts about this error message, but only when they apply to custom STS. I'm using Geneva beta 2. I add my website as a relying party. I ran fedutil to link my relying party site to the Geneva server and everything seems great. Did a few tweaks to the web.config to allow the token to pass through request validation.

    Now as soon as I get the token from the Geneva server, I get this error message.

    The identifier for my app looks like this : https://server/app.Namespace
    There is one ws-federation passive endpoint: https://server/app.Namespace

    I am not encrypting tokens or anything else and haven't done anything custom at all.

    Here is the full stack trace:
    [FederationException: ID3206: A signin response may only redirect within the current web application: '/test.Web' is not allowed.]
    
       Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request) +1064
    
       Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args) +521
    
       System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +80
    
       System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +266
    
    

    I did some poking around in .NET Reflector and it looks like the thing that triggers this failure is code that looks like this:
    if (!ControlUtil.IsAppRelative(returnUrlFromResponse))

    So, for whatever reason, it thinks that the redirect URL for my application is absolute instead of relative. Is there any way to fix/debug/troubleshoot this in Geneva Beta 2?


    The .NET Addict - http://dotnetaddict.dotnetdevelopersjournal.com
    Tuesday, December 1, 2009 1:33 PM

All replies

  • Ok, so this is a pretty ridiculous bug.

    If I hit the URL  https://server/myapp/ then the redirect works. When I hit https://server/myapp (with no trailing slash), then the redirect does NOT work (it thinks I'm using an absolute URI instead of relative).

    Now of course I'm having an issue where i'm not getting the name back from the Geneva Beta 2 server - my app thinks I'm authenticated but my name is null. do I need to manually spit this claim back as a claim rule for the relying party? I thought it did this automatically for AD claims?
    The .NET Addict - http://dotnetaddict.dotnetdevelopersjournal.com
    Tuesday, December 1, 2009 2:57 PM
  • Yeah, I ran into this issue as well.    More specifically:

    <Non functional rp web.config / FederationException: ID3206>
     <wsFederation passiveRedirectEnabled="true" requireHttps="false" issuer="http://localhost.:82/sts/wsfederation/signin" realm="http://localhost.:81/zfp" />

    <Functional rp web.config>
     <wsFederation passiveRedirectEnabled="true" requireHttps="false" issuer="http://localhost.:82/sts/wsfederation/signin" realm="http://localhost.:81/zfp/" />

    End users might not always remember the trailing slash.    Any work-around for this issue or plans on changing this behavior?

    Note, I am using W.I.F. 3.5.0.0


    thanks

    Thursday, January 7, 2010 9:15 PM
  • I have the same issue, if users go to the relying party URL without the trailing slash they get

    ID3206: A signin response may only redirect within the current web application: XXXXXX is not allowed.

    Are there any solutions to this problem?

    Thanks
    Monday, January 25, 2010 11:27 PM
  • I just ran into this issue with the RTM version as well, so it doesn't appear that anything was done to mitigate this.

    Is the official Microsoft recommendation to ensure that users are putting a trailing '/' on their URL? If so, I guess my next question would be....really? :)

    Friday, May 14, 2010 11:50 PM
  • Can someone from Microsoft answer how can we workaround this problem?
    WBR, Viktor
    Wednesday, July 7, 2010 3:06 PM
  • Thanks for reminding me.  I just submitted this via Microsoft connect.   Please upvote this issue if it pertains to you.

     

    https://connect.microsoft.com/site642/feedback/details/573589/wsfederationauthenticationelement-web-config-requires-trailing-slash-after-home-realm-otherwise-an-error-occurs

     

     

    Wednesday, July 7, 2010 3:27 PM
  • This definately needs to be fixed. This is really frustrating. I upvoted the issue too Scott.
    • Proposed as answer by Jeremy Lew Thursday, August 26, 2010 6:25 PM
    Friday, July 9, 2010 7:24 PM
  • Workaround: Add a handler in global.asax like the one below which detects the "no-trailing-slash" situation and redirects to the same path with the slash appended.  This happens before the FAM gets its hands on the request, and the signon process will proceed without error:

    private void Application_BeginRequest(object sender, EventArgs e)
    {
           if ( String.Compare( Request.Path, Request.ApplicationPath, StringComparison.InvariantCultureIgnoreCase) == 0
               && ! ( Request.Path.EndsWith("/") ) )
                   Response.Redirect(Request.Path + "/");           
    }

    • Proposed as answer by Jeremy Lew Thursday, August 26, 2010 6:27 PM
    Thursday, August 26, 2010 6:27 PM
  • Workaround: Add a handler in global.asax like the one below which detects the "no-trailing-slash" situation and redirects to the same path with the slash appended.  This happens before the FAM gets its hands on the request, and the signon process will proceed without error:

    private void Application_BeginRequest(object sender, EventArgs e)
    {
           if ( String.Compare( Request.Path, Request.ApplicationPath, StringComparison.InvariantCultureIgnoreCase) == 0
               && ! ( Request.Path.EndsWith("/") ) )
                   Response.Redirect(Request.Path + "/");           
    }


    I put this code in my ASP.NET mvc RP app, and it just redirects back to the signin page instead of the rp.

     

    • Edited by scott_m Tuesday, September 14, 2010 2:31 AM more detail
    Thursday, August 26, 2010 7:16 PM
  • Nobody solved this problem yet? Is really frustrating
    Wednesday, October 27, 2010 3:27 PM
  • Workaround: Add a handler in global.asax like the one below which detects the "no-trailing-slash" situation and redirects to the same path with the slash appended.  This happens before the FAM gets its hands on the request, and the signon process will proceed without error:

    private void Application_BeginRequest(object sender, EventArgs e)
    {
           if ( String.Compare( Request.Path, Request.ApplicationPath, StringComparison.InvariantCultureIgnoreCase) == 0
               && ! ( Request.Path.EndsWith("/") ) )
                   Response.Redirect(Request.Path + "/");           
    }


    I put this code in my ASP.NET mvc RP app, and it just redirects back to the signin page instead of the rp.

     


    This workaround worked fine for me and it will be good enough until Microsoft fixes this.

    Before changing back the AudienceUri, Realm etc. to use the trailing '/' i got the result you are describing.


    magohl
    Tuesday, November 30, 2010 9:41 PM
  • Hi,

     

    I am getting the same problem..

    Here is my situation

    I have a mvc 2.0 application that is using adfs for authentication. I have added the sts reference, added relying party on the server etc..

     

    <federatedAuthentication>
            <wsFederation passiveRedirectEnabled="true" issuer="https://[adfs server]/adfs/ls/" realm="https://[my IIS server]/[my app]/" requireHttps="true" />
            <cookieHandler requireSsl="true" />
          </federatedAuthentication>

    as you can see I have the trailing slash, as I was aware of this problem anyway.

     

    My relying party identifier(on adfs server) is https://[my IIS server]/[my app]/ as is the endpoint, both with the "/" at the end..

    I still get the error that is being discussed here. I tried putting in the code above to see what happened, and when i access on the IIS server, the page just looped and looped

     

    Has anyone got anymore ideas, all the posts etc just have the above suggestion :(

     

    Cheers,

    J

    • Edited by The Mod Wednesday, December 15, 2010 12:10 PM typo
    Wednesday, December 15, 2010 12:10 PM
  • I too experienced a problem with implementing the suggested fix in the Application_BeginRequest event handler. What worked for me was this:

    (in global.asax)

    void Application_Error(object sender, EventArgs e)
    {
      var ex = Context.Error;
      if (ex is Microsoft.IdentityModel.Protocols.FederationException)
      {
        if(ex.Message.StartsWith("ID3206:"))
        {
          if (String.Compare(Request.Path, Request.ApplicationPath, StringComparison.InvariantCultureIgnoreCase) == 0
            && !(Request.Path.EndsWith("/")))
            Response.Redirect(Request.Path + "/");
        }
      }
    }
    

    So it's based on Jeremy's initial suggestion, it just handles the error.

    I don't think it's ideal, though.

     

    -S

    Wednesday, March 16, 2011 7:22 AM
  • Can someone from Microsoft clarify if this issue has been fixed in WIF 4.5?

    Saturday, September 8, 2012 3:18 AM
  • I took a look in the WSFederationModule overridable functions.

    I noticed that RedirectToIdentityProvider is called before sending the browser to the sts. This function has a parameter returnUrl which has the relative to the host path.

    At this point you can manipulate the returnUrl to include the trailing slash, so when return from the STS, WIF thinks that your original call was made with the trailing slash.

    You must be careful not to confuse with the MVC urls. I used the realm value from the configuration to find whether the request is on the root level.

            public override void RedirectToIdentityProvider(string uniqueId, string returnUrl, bool persist)
            {
                //This corrects WIF error ID3206 "A SignInResponse message may only redirect within the current web application:"
                //First Check if the request url doesn't end with a "/"
                if (!returnUrl.EndsWith("/"))
                {
                    //Compare if Request Url +"/" is equal to the Realm, so only root access is corrected
                    //https://localhost/AppName plus "/" is equal to https://localhost/AppName/
                    //This is to avoid MVC urls
                    if (String.Compare(System.Web.HttpContext.Current.Request.Url.AbsoluteUri + "/"base.Realm, StringComparison.InvariantCultureIgnoreCase) == 0)
                    {
                        //Add the trailing slash
                        returnUrl += "/";
                    }
                }
                base.RedirectToIdentityProvider(uniqueId, returnUrl, persist);
            }

    I think this solution is better because this event is triggered once before redirecting to the sts. So it doesn't put the overhead or complexity to the global_asax.
    • Edited by Sarafian Monday, November 5, 2012 11:22 AM
    Monday, November 5, 2012 11:11 AM
  • @Sarafian - thanks for this.
    Wednesday, November 28, 2012 10:45 AM