Sunday, March 29, 2015

Anonymous access of SharePoint content in authenticated SharePoint context

Intranets, or better Digital Workplaces, provides employees with access to business information and functionalities. Typical the access is authorized, role-based and sometimes on individual level. In both cases it is requires that the intranet users are first authenticated to next check the authorization for the authenticated visitor. This is why intranets are typically authenticated, while external-facing sites have anonymous access enabled.
Webapplications utilize resources of diverse types for branding the site: css, images, and javascript code. Authorization on these items is most times unnecessary, as it is “code” and not (role) sensitive information. SharePoint-based portals often store these static resources as ‘content’ in a SharePoint style library. In Office 365 context it is the only possible approach to provision branding resources, deployment to the layouts folder requires access to the SharePoint farm.
SharePoint authentication handling adds some overhead to the basic execution of the http request. For instance in case of NTLM authentication, each http connection between client and SharePoint must negotiate the authentication state via the NTLM handshake, adding 2 requests (type 1 and type 2) before SharePoint responds on the actual client request. Although this overhead is in absolute value small on indivual request level, the impact can become noticable when the number of http requests increases.
So I considered it a good idea to enable anonymous access on the style library, and as such avoid this authentication-overhead for the static resources retrieved from SharePoint content database. The result is that direct retrieval of any resource stored in the style library does not involve authentication processing. However, to my initial surprise the authentication is still applied when the resource is retrieved in context of an authenticated SharePoint page. I compared the http requests send from the 2 different situations, and noticed that in the situation requested from authenticated SharePoint context the http request includes the NTLM authentication header. And in that case, even although the style library on itself does allow anonymous access, as the http request includes NTLM authentication information, IIS “honors” this and still sets up the NTLM authentication handshake with the browser.
Conclusion: anonymous access to SharePoint data is not possible whenever that data is retrieved in context of an authenticated SharePoint page on the same webserver domain. Successful anonymous access requires to break out of the authenticated SharePoint context. E.g. by storing the static resources in another webapplication and have the authenticated SharePoint page refer to the resources on that other webapplication and thus another domain for which the authentication cookie from the authenticated SharePoint page does not apply.

Sunday, March 22, 2015

SharePoint App-Model + NTLM results in more 401’s

We have built our new intranet in SharePoint 2013. Concept of the renewed intranet is it’s branding as Digital Workplace. Employees are enabled to personalize the digital workplace to their own needs and likes. Business functionalities, but also utilities are all provided as SharePoint Apps.
Upon monitoring the http transfer in Fiddler, I notice a lot of 401’s.
My reasoning on what causes this is the following:
  1. We apply NTLM for SharePoint authentication. When the browser addresses the remote webserver over a new http connection, IIS responds with Http 401 to start the NTLM handshake with the browser.
  2. The browser in parallel requests resources at the webserver over multiple http connections, of which each must setup an own authenticated session with the remote webserver. IE9 is limited to maximum 6 http connections, IE10/11 can open 32 in parallel.
  3. SharePoint defaults to the HTTP Keep-Alive response header. This results that the browser can reuse an already authenticated http connection to request additional resources. The subsequent requests are directly responded with http 200 by the remote webserver.
  4. Unless..., the subsequent resources are addressable on another domain. In that case, the authenticated http connection cannot be reused. And the browser must setup a new http connection to the other domain. If the other domain is also an authorized resource, a new authentication handshake results between the remote server of this domain, and the browser.
  5. And this is exactly what occurs with the App-model. The SharePoint site is addressable on a domain, but for App isolation the Apps are addressable on one or more App-domains. Opening a SharePoint page with one or more Apps on it, results in request(s) send to the SharePoint hostweb domain, followed by request(s) send to one or more appweb domains.
Sequence, largely simplified