Extranet Double Authentication

GE-old problem that still exists today in SharePoint, is the double message authentication when trying to open an Office document that appears continuously (note: this is when working with a document more. In reading does not require authentication only, and do not interact with the document). This happens because of the nature of passing a logon token from the user's session to mount. Meaning, when you open an Office application, you can not lead to the web session in the client session (and the session is the appropriate user ID) because the session ID is considered new, SharePoint will try to verify user identity again. Ultimately, it would be great if the identity of Windows you are using SharePoint would persist through this border, however, is not in the cards now. The first mechanism is to move WSS v3 has an option that is available called "Extranet Mode". Extranet so disable all interface features that could cause the message to pass, but becomes part of the best document management features such as WebDAV dependent (Explorer View) and ActiveX (Upload multiple documents). The other option is to use forms-based authentication with persistent cookies. In general, writing a cookie to the client browser has mixed feelings about whether this is a viable security practice or not, but ASP.NET 2.0 Cookies are by default considered tamper-proof and encrypted .



I've read that many companies offer some type of application optimizers or whatever, anyway I'm not for a COTS solution since most customers will nix anyway, I think the fear OOB security solution when the code is not da. I know you can use ISA to solve it, but I've only seen one other solutions to this which solved my fine things in an extranet scenario. ISA tends to be a problem and for some organizations because, although not built in mechanisms that will help secure the release of a web server, it requires additional hardware, requires knowledge of ISA, an architect for the construction of an instance of ISA, and a person with the ISA manager (for things like connectivity verifiers and link the tasks of translation).



So they tend to lean toward a VC + + ISAPI filter (could accomplish the same thing with XMLHTTP ActiveX or I'm not sure.) To intercept the requests as are pipes in SharePoint as an ISAPI filter will be able to inject any more times during the life of a user request. Generally, you can customize the ISAPI filter to build the same type of persistent cookie with FBA offered with Windows authentication schemes such as basic or integrated authentication through an extranet. This would be quite easy to build as the ISAPI filter can intercept HTTP requests as the last user if the cookie does not exist create a new cookie with a session and GUID if the cookie exists extract the GUID cookie and finally passed all this information by the extensive use of the head of the streaming application for approval of IIS.



Although I am 100% sure this route works well, the writing unmanaged code is not particularly lucrative several options because most people (like me) have been spoiled by the existence of so long. Only wants to go again in unmanaged really do not like (even with the help of being able to build an ISAPI filter Skelton.
To write an ISAPI filter for SharePoint, you will have to investigate the construction of at least two entry points GetFilterVersion and HttpFilterProc. GetFilterVersion is the main entry point for the ISAPI filter structure HTTP_FILTER_VERSION taking as a parameter, which will determine the website to request notifications encountered by the ISAPI filter, or is to preprocess headers (as in the example below ) and priority flags that should be related. Basically, what tells the filter to listen, and the creation of an initial call for the first time.