Lane Goolsby

Lane is a Senior Software Engineer for ThreeWill. He is a strong technology expert with a focus on programming, network and hardware design, and requirements and capacity planning. He has an exceptional combination of technical and communication skills.

We’ve cherry-picked internal Yammer conversations that might be helpful to the community – this one comes from Lane Goolsby about using ADFS Auth with SharePoint.

[Original Yammer Post – Lane Goolsby – June 6 at 10:27am]

I learned something recently that frankly I am surprised I have never ran into before. Since we are starting to do more Single Page Apps (SPA) I figured I would share as it may have impacts to design and architecture, and certainly impacts implementation with SPA.

If you are using ADFS auth with SharePoint, when a user is authenticated they are provided the Fed Auth cookie as we all have seen one time or another. However, what isn’t readily apparent is that the fed auth cookie only lasts for an hour – period. Now, the user’s session with ADFS is good for up to 8 hours with ADFS (by default) but every 60 minutes (again, by default) the user’s browser will get a HTTP 302 redirect from SP back to ADFS to refresh the auth token.

The 60 minute timeout for the session token is not a sliding session. Meaning, if the user is clicking around and ‘doing stuff’ in SP the token is not updated to [Now + 60]. So in theory a user could click around for 59 minutes then try to upload a file at 60:01 and will have to get a new auth token from ADFS. This doesn’t appear to be too bad if the user is working from within the browser since the browser handles the redirects gracefully and ADFS has some tricks in place to handle form POST data on the return trip to SP.

However, if the action taken at 60:01 is a GET or POST made from $http or $.ajax, then things go all crab. This is because the redirect response from SP ends up throwing a monkey wrench into the equation.

[Kirk Liemohn – June 6 at 11:19am]

Thanks for raising this issue. @Brandon Holloway, you may want to include a test case for this.

[Lane Goolsby – June 9 at 6:11pm]

I am still researching ways to address this but as of right now there are only two viable ‘fixes’ I can find. The first is to enable sliding sessions in SP via PoSh (there are few examples if you Google for it). The second fix is probably the ideal fix but is also the most complicated (I suspect). In short, make the JavaScript code smart enough to chase the redirects. I have found anecdotal evidence that browsers should actually handle all of this automagically (at least for $http) but so far this does not actually appear to be the case.

After spending most of the past couple days looking at this I think I have the root cause clearly understood. The issue is when the AJAX call is made to one of the SP REST endpoints but the token has reached its 60 minute threshold, SP issues a HTTP redirect response code back to ADFS. The problem is this triggers the CORS routines within the browser. IF ADFS used IIS instead of http.sys this wouldn’t be a big deal and we could just add the CORS headers to ADFS to allow the preflighting to pass. But alas. I am still trying to find a viable solution, but so far all the ideas we have thought of either don’t work or are sub optimal.

[Lane Goolsby – June 13 at 3:28pm]

So after dealing with this for what seems like an eternity I have two viable solutions identified.

Option 1: Enable sliding as I mentioned before. There are security risks with this approach so highly advised against if traffic is going over the internet or content is sensitive.

Option 2: Use a reverse proxy between ADFS and the browsers to inject the Access-Control-Allow-Origin header into all responses. I used IIS as reverse proxy using the URL Rewrite module and added the HTTP headers in IIS. This is probably not a viable production configuration, but you should be able to lock it down to make it ready for prime time.

Links you will likely need:
http://weblogs.asp.net/owscott/creating-a-reverse-proxy-with-url-rewrite-for-iis
http://www.carlosag.net/articles/enable-cors-access-control-allow-origin.cshtml
http://www.iis.net/learn/extensions/url-rewrite-module/modifying-http-response-headers
https://www.tylenol.com/