Had a very strange issue today. We have a WCF-service based system we're deploying on a client's network. One of the services uses Basic Authentication for normal calls, which is handled via a custom HttpModule. However, one specific subfolder of the WCF service (/downloads/) we wanted to have only anonymous auth so that files could be downloaded without a password.
It seemed like it should be relatively straightforward. I modified the logic in the Basic Auth module to skip authentication step for any path starting with /downloads/. It worked beautifully in our testing environment. However, the problems began when we moved the code into our client's network. Every time I would try to access a url containing /downloads/, I would incorrectly get the Basic Auth prompt, even though it was supposed to be exempted.
In an attempt to debug the issue, I commented out the Basic Auth module completely from web.config so the website would use Anonymous Auth globally. However, when I tried to access any path in the service from a web browser, it would generate a 401.3 error, which is a physical ACL access denied error. It didn't make any sense that the account should be disabled from access because the identity pool account for the IIS website had full permissions to the folder containing the service files.
After doing a little research I discovered that the account used by default for anonymous auth is specified separately from the account for the identity pool. Even if you specify in the global Website Basic Settings that the "Connect As" should be Pass-though (Application Pool Identity), that is separate from the setting for Anonymous Auth. Turns out if you right-click on the Anonymous Auth setting in an IIS site, you can specify the account used for requests made as Anonymous, and by default the account is IUSR. We changed this to use the application pool identity and it started working beautifully.
However, this leaves me somewhat puzzled as to how the Basic Auth account was working when the Anonymous Auth is not working. The Basic Auth accounts are tied to a database, which is entirely segregated from the ACL-level permissions in windows, which are tied to Active Directory in the network. Apparently, it seems that just by fact of using Basic Auth with any account, it uses the Application Pool Identity, but if you have no username at all, then it assumes the Anonymous Auth default user setting - regardless of whether your Basic Auth username has anything to do with the network. Very unexpected behavior, and very frustrating to debug.
Happy programming!
No comments:
Post a Comment