SECURITY
Although it is atypical to combine DSAPI authentication customizations and Windows single sign-on for Web clients, an example scenario is a DSAPI filter which regulates access to a particular server URL, while other server URLs are accessible after standard Domino authentication. To regulate access to a particular URL, the DSAPI filter might facilitate custom login processing, perhaps calling out to a third party system that verifies the user and establishes additional expected credentials. In this case, it is required that the DSAPI filter handles all aspects of the authentication (such as providing the application login page and processing the login inputs) in order for the DSAPI filter to operate successfully in the environment that also includes Windows single sign-on for Web clients. If a DSAPI filter successfully handles the user authentication, there is no need for Domino to authenticate the user and the Windows single sign-on will not take place.
Certain types of DSAPI authentication filters cannot be supported with Windows single sign-on for Web clients. A DSAPI filter which relies on the Domino login page to collect user names and passwords cannot be supported, since the Domino login page will not be presented to the user in the Windows single sign-on environment. A DSAPI filter cannot be supported if it relies on user names and passwords to be sent to the Web server in basic authentication headers. Furthermore DSAPI filters which extend Domino to provide the SPNEGO protocol are not supported when Windows single sign-on for Web clients is enabled, because of interference with core Domino's handling of Windows single sign-on. If you need to continue using a DSAPI filter which is incompatible with Windows single sign-on for Web clients, you should deploy your incompatible DSAPI filter in a separate Web Site from those Web Sites that are enabled for Windows single sign-on for Web clients.
Related topics