locked
Enabling Persistent Cookies? RRS feed

  • Question

  • Hi Folks,

    i'm looking for a way to enable "persistent cookies" in UAG to get a real Single-Sign-On for Office/WebDav application when accessing published SharePoint documents or libriaries.

    The scenario would be that the users login to UAG Portal and access a published SharePoint site. Then the user would click on a Word document and Office will automatically reuse the UAG Session Cookie to authenticate back to UAG. This would eliminate the somewhat unsecure "Allow rich clients to bypass trunk authentication" mode in our scenario.

    In ISA/TMG its an easy task to enable persistense cookies, but in UAG i couldn't find a guide how to enable nor even an information if its supported or not.

    So anyone has a solution for this or knows if its supported or not?

    -Kai Wilke

     

    Wednesday, July 27, 2011 9:50 AM

Answers

  • If you access SharePoint via UAG first, you will be able to use office applications without needing to re-authenticate. The Allow rich clients to bypass trunk authentication option is designed to cover the scenario where you access a SharePoint URL directly from the office applications without first accessing SharePoint in the web browser. A common scenario for this is using the Recent Documents area in Word, after you have closed the web browser.

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by Kai Wilke Saturday, August 13, 2011 11:56 PM
    Wednesday, July 27, 2011 1:50 PM
  • Hi Jason, 

    thank you for your reply it was very helpful for pointing me to the right direction!

    Based on additional testing our problem relies in the fact that UAG uses two different cookies when accessing SharePoint sites.

    The first cookie (non-persistent) gets pushed to the client when the UAG Portal is getting initialized. This cookie will be used by the browser every time it access the UAG Portal Trunk.

    Once the client launches the published SharePoint application, a second cookie (persistent!) gets generated on the client site using JavaScript. The hook for the JavaScript gets embedded into “/_layouts/1031/init.js” (injected via AppWrap) which calls “/InternalSite/sharepoint.asp” to generate and set the persistent Logon cookie on the client.

    So the solution for our problem is to make sure the users will open the SharePoint Application before they're going to use the rich client applications. Just logging into UAG and access the SharePoint using RichClients wouldn’t work in this case.

    Well, I’ll do further investigations if a simple UAG customization can set the second cookie after the UAG Portal initializes. On this way the users could launch their applications without to remember accessing the SharePoint site(s) in before.

    Thanks dude!

    -Kai Wilke

     


    • Marked as answer by Kai Wilke Saturday, August 13, 2011 11:56 PM
    Wednesday, July 27, 2011 3:52 PM

All replies

  • If you access SharePoint via UAG first, you will be able to use office applications without needing to re-authenticate. The Allow rich clients to bypass trunk authentication option is designed to cover the scenario where you access a SharePoint URL directly from the office applications without first accessing SharePoint in the web browser. A common scenario for this is using the Recent Documents area in Word, after you have closed the web browser.

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by Kai Wilke Saturday, August 13, 2011 11:56 PM
    Wednesday, July 27, 2011 1:50 PM
  • Hi Jason, 

    thank you for your reply it was very helpful for pointing me to the right direction!

    Based on additional testing our problem relies in the fact that UAG uses two different cookies when accessing SharePoint sites.

    The first cookie (non-persistent) gets pushed to the client when the UAG Portal is getting initialized. This cookie will be used by the browser every time it access the UAG Portal Trunk.

    Once the client launches the published SharePoint application, a second cookie (persistent!) gets generated on the client site using JavaScript. The hook for the JavaScript gets embedded into “/_layouts/1031/init.js” (injected via AppWrap) which calls “/InternalSite/sharepoint.asp” to generate and set the persistent Logon cookie on the client.

    So the solution for our problem is to make sure the users will open the SharePoint Application before they're going to use the rich client applications. Just logging into UAG and access the SharePoint using RichClients wouldn’t work in this case.

    Well, I’ll do further investigations if a simple UAG customization can set the second cookie after the UAG Portal initializes. On this way the users could launch their applications without to remember accessing the SharePoint site(s) in before.

    Thanks dude!

    -Kai Wilke

     


    • Marked as answer by Kai Wilke Saturday, August 13, 2011 11:56 PM
    Wednesday, July 27, 2011 3:52 PM
  • Be aware that persistent cookies have their own risks too ;)
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, July 27, 2011 9:59 PM
  • Oh well, since UAG already uses persistant cookies it wouldn't cause an additional threat. Its just a different timing when the cookies are getting generated...

     

    -Kai

     

    Thursday, July 28, 2011 8:28 AM