locked
Does UAG handles cached cookies with IE different than with other browsers RRS feed

  • Question

  • Hi All,

    I have the following situation:

    We use UAG to publish a websphere portal and to simulate SSO i've configured form based authentication within UAG. The flow looks like:

    The application URL of my Portal home page application is: http://portal.company.com/extern/redirect/. When the browser opens this URL it gets redirected to a login page, this login page includes a form that is processed by UAG and submitted. After that submit there are 2 scenario's:

    1. My browser is Internet Explorer 8;
    I get redirected to the login page, UAG processes the form, submits, i get redirected again.... i'm stuck in a loop.

    2. My browser is Firefox, Chrome or Safari:
    I get redirected to my company portal, this is the expected behavior.

    I've debugged my http traffic and after the submit there is a GET for the extern/redirect/ url with some response headers and i've noticed the following differences:

    With Firefox, Chrome or Safari:
    Cache-Control: public,post-check=86400,pre-check=604800

    Internet Explorer:
    Cache-Control: no-cache="set-cookie, set-cookie2",public,post-check=86400,pre-check=604800
    Expires: Thu, 01 Dec 1994 16:00:00 GMT

    It looks like when it does the GET some (authentication) cookies are gone (no-cache, expired) and therefor i have to login again.

    I've also tested this without UAG and then i get for Internet Explorer the same result as with Firefox, Chrome or Safari, it works fine...

    Does anybody have an idea what causes this behavior and what are the differences for IE and other browsers in combination with UAG?

    Thanks

    Tuesday, May 24, 2011 7:59 PM

Answers

All replies

  • Hallo Maikel,

    The answer is no, UAG does not changes the way it processes cookies based on the user-agent/browser.

    Just to update the forum, I know that since you posted this question here on the UAG forum, you have made some progress in investigating the reason for the loop. You took a Fiddler trace and discovered the following: after UAG performs SSO to the WebSphere logon page, a Set-Cookie header is sent by the WebSphere server, which although it reaches the browser via UAG as expected, is not returned back by the browser upon its next HTTP request, hence causing the WebSphere server to reply again with its logon page. And since UAG has been configured to perform SSO to this logon page, the process repeats itself, in a continuous loop.

    Currently, it is still undetermined why does the browser ignore or refuse the cookie sent by WebSphere.

    Regards,


    -Ran
    Wednesday, May 25, 2011 3:04 PM
  • The problem seems to be the domain name we are using, this is a 2 letter-domain: http://portal.xx.com. According to this article IE recognizes this as a top-level domain http://support.microsoft.com/kb/310676/en-us.

    Solution for this problem:

    UAG rewrites the cookie domain attribute from xx.com to portal.xx.com. Now the cookie is returned back by the browser upon its next HTTP request.

    I've configured UAG for cookie rewriting following this article:  http://technet.microsoft.com/en-us/library/dd278130.aspx.

    Regards,

    Maikel.

    • Marked as answer by MvanWesteneng Wednesday, June 29, 2011 11:41 AM
    Wednesday, June 29, 2011 11:41 AM
  • Interesting! Thank you for updating the forum, Maikel.

    Regards,


    -Ran
    Wednesday, June 29, 2011 12:22 PM
  • Hi Maikel,

    i have the same issue with a two letter domain.

    Can you tell me which file i have to modify? do you have modified the original files or created a CustomUpdate Folder?

    I have a Sharepoint publishing in a https trunk. The Portal Application is not in use, only the sharepoint.

    I would like to change the cookie from xx.ch to sp.xx.ch.

    Thank you and best regards

    Marc

    Thursday, September 1, 2011 8:26 AM
  • Hi Marc,

     I did this in the SRA file WhlFiltSecureRemote_HTTPS.xml, where the HTTPS depends on your trunk type (http or https). Always use the CustomUpdate folder! Location of the file:

    C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\WebSites\ns\conf\CustomUpdate\WhlFiltSecureRemote_HTTPS.xml'

    I've inserted something like this:

    <COOKIES_HANDLING>
    	<APPLICATION>
    		<APPLICATION_TYPE>ApplicationTypeName</APPLICATION_TYPE>
    		<Set-Cookie>
    			<NAME>CookieName</NAME>
    			<Domain>sp.xx.ch</Domain>
    		</Set-Cookie>
    	</APPLICATION>
    </COOKIES_HANDLING>

    Hope this works for you!

    Maikel.
     

    Thursday, September 1, 2011 2:34 PM
  • Hi Maikel,

    thank you very much.

    I have tried to apply this settings but i have no success.

    Is it possible to get the whole CustomUpdate File from you? Maybe i have a syntax error in my file.

    You can send me the file to marc.gut@bison-its.ch

     

    The Cookie Name i would like to change is NLSessionS[trunkname]. I try to change the Domain Attribute.

     

    Best Regards

    Marc

     

    Friday, September 2, 2011 6:29 AM
  • Hi Marc,

    Modifying UAG's NLSessionS[trunkname] cookie, which is the UAG session cookie, is not something that you will be able to achieve through the means of an SRA or an AppWrap.

    SRA and AppWrap make changes to the HTTP content that passes through UAG, on its way to and from backend web servers published though UAG. This includes the InternalSite, PortalHomePage, and FileSharing sites running on UAG's default web site at localhost:6001, as well as the WebMonitor sites running on UAG at localhost:50002).

    However, the UAG session cookie is not set by a backend web site, including the ones running on ocalhost:6001 or localhost:50002. The NLSessionS[trunkname] or NLSessionC[trunkname] are set by the core UAG components, and added to the HTTP traffic sent to the client, and therefore these cookies (and some other UAG cookies) do not pass through SRA or AppWrap.

    Regards,


    -Ran
    Sunday, September 4, 2011 7:39 AM
  • Hi Ran,

    thank you.

    Now it makes sense :)

     

    I was able to solve the problem by setting the portal public name to the same as the sharepoint publishing name.

    With this configuration no Domain Session Cookie is set and the old Browsers are working.

    But this is in my opinion only a workaround. As soon as we publish a second application, i think the problem will come back.

    Thank you and best regards

    Marc

    Thursday, September 8, 2011 7:22 AM