Circular redicrect and case sensitive uris

Tue, 25 Nov 2008 12:42:12 Z

Hello again

I might be missing something very trivial here....apologies if I do.

I to have bumped into the circular redirects between the RP and the passive STS, and my understanding of the cause makes very little sense, so I have to assume I misunderstand something.

The circular redirect - where the RP redirects to the STS which redirects to the RP which redirects back to the STS and so forth, is happening when there is a case-sensitive mismatch between the url I type for the RP in the browsers and the uri in IIS (the virtual directory name)

So - if I have a virtual directory called TestPortal and I browse to http://localhost/TestPortal everything works finel; if, however, I browse to http://localhost/testportal I get the circular redirect.

If I changed the casing of the Vdir (which is not a one step, as the IIS manager, like the FS, is not case sensitive) to be "testportal" then the opposite occures - requests for http://localhost/testportal work and requests to http://localhost/TestPortal don't.

All of this seems to be irrespective of what's in the Realm and AudienceUri for the RP.

This seems odd, especially as I can't control what the users are going to type in the browser....to the point that I doubt I got it right....why is this happening then? how I can I ensure the problem never appears?

Thanks

Yossi

Yossi Dahan

Circular redicrect and case sensitive uris

Wed, 26 Nov 2008 01:43:00 Z

Hi Yossi,

If your RP is based on the Geneva Framework, can you provide me with the Audience URIs that you configured for your RP?

Thanks,
Abhijeet.

Circular redicrect and case sensitive uris

Thu, 27 Nov 2008 16:08:54 Z

In one of my tests I've put

    <audienceUris> 
      <add value="https://localhost/TestPortal"/> 
    </audienceUris> 

This does not seem to be case sensitive though - I could have put it all lower case with no impact.

Yossi Dahan

Circular redicrect and case sensitive uris

Sat, 06 Dec 2008 23:59:04 Z

The problem stems partially from the way cookies are managed by the browsers. Only cookies for the requested domain and path are included with the request, and the path portion of the URL (TestPortal in your case) is case-sensitive.

So the cookie is written for the path in the request (testportal) and is not included with requests for TestPortal. This will prevent you from authenticating at TestPortal.

The circular redirection is a bug in the Framework. The STS is redirecting back to the URL specified in the realm or the wreply, which is TestPortal. Since the cookie is not sent the previous authentication isn't recognized and a repeated request is sent to the STS.

This issue has been filed with the development team. As a workaround, you might add a handler to rewrite the requested path into a canonical form, such as lowercase.

Thank you for identifying this problem.

Circular redicrect and case sensitive uris

Wed, 10 Dec 2008 09:41:02 Z

Thanks for the reply Peter.

1. Would you be able to post a quick pointer into the handler I would need to write? I'm not generally deep into web development...

2. If I understand your reply correctly you are saying that the circular redirect is a bug that will be fixed, but you also say that the need to authenticate again if the user typed the "wrong" url casing will remain?

Can you explain that last point a bit more? I don't fully understand it...

Thanks in advance

Yossi

Yossi Dahan Connected Systems MVP

Circular redicrect and case sensitive uris

Sat, 13 Dec 2008 07:49:22 Z

1. I was thinking of an HttpHandler that would lowercase all the paths coming into the app, but I realize now that won't work... as seen in...

2. If the application path (virtual directory) is MyApplication, cookies written will be scoped by default to MyApplication. If the user types myapplication, the browser will not send the cookie back to the site. A handler won't work because the request is already cookieless. The app can't reauthenticate without the cookie.

To prevent this, you can specify the path that will scope the cookie to "/". Then cookies will be sent to any path on the domain, and the domain is matched case-insensitively (if that's a word). That can be done in web.config. By default the path is the virtual path of the application.

<federatedAuthentication> 

  <cookieHandler path="/" /> 

</federatedAuthentication> 

Circular redicrect and case sensitive uris

Sun, 14 Dec 2008 20:42:12 Z

Thanks Peter,

Initial test proves this to work, and that solution is good enough for me for now.

Thanks for picking this up.

Yossi Dahan | [To help others please mark replies as answers if you found them helpful]

Circular redicrect and case sensitive uris

Wed, 20 May 2009 14:39:30 Z

I'm coming back to this now as I've just realised why this is not such a good idea! :-)

As far as I can tell, as the token with the cookie is now stored at the root of the domain, it would apply to any web site hosted in this domain.

so - if I have SomeDomain.com/ApplicationA and SomeDomain.Com/ApplicationB and a user tries to browse to ApplicationA she would be redirected to the STS, log in, and the cookie would be stored under SomeDomain.com.

What that user will now browse to ApplicationB, the STS would not be called again, the same token would be issued; this is OK if the user is allowed to use both and the claims are identical, but not so ok if the user should only be allowed to one app, or if the 2nd app requires a different set of claims.
I thought the realm would come into play here (as both apps are different realms), but it does not seem to make a difference...

Yossi Dahan | [To help others please mark replies as answers if you found them helpful]