This problem was ultimately caused because the directory where the files were hosted was not accessible to the IUSR account (this was despite the fact that it was accessible to "NETWORK SERVICE" and the application pool identity). When I was testing on a fresh IIS7 installation I was copying the directory tree into \inetpub\wwwroot where IUSR already had access.
It still isn't clear why this problem exhibited itself as a redirect to the login page (as though it was not propagating authorization settings properly) but I did identify some problems with the configuration of forms authentication.
This part is critical because everything I have found doesn't correctly (or adequately) explain this.
Virtually everywhere I searched I found the following settings for web.config.
<configuration>
<system.web>
<authentication mode="Forms">
<forms loginUrl="~/login.aspx" />
</authentication>
<authorization>
<deny users="?" />
<allow users="*" />
</authorization>
</system.web>
</configuration>
The way this is generally explained is that this unauthenticated users are redirected to login.aspx and authenticated users are granted access.
In fact, this configuration section only applies to ASP.NET pages (aspx). Any other types of content (html, asp, jpg, etc) are not governed by this configuration.
To protect these types of content you must have "IIS 7 URL Authorization" installed and it requires the web.config section under as shown below.
<system.webServer>
<security>
<authorization>
<clear />
<add accessType="Deny" users="?" />
<add accessType="Allow" users="*" />
</authorization>
</security>
</system.webServer>
I saw one place that explained the difference between and as IIS6 vs IIS7 but this isn't completely accurate. There are different authorization mechanisms for different types of content and You need both if you want to restrict access to non aspx pages.
Best Answer
Take a look at this article: http://mvolo.com/blogs/serverside/archive/2008/02/11/IIS-7.0-Two_2D00_Level-Authentication-with-Forms-Authentication-and-Windows-Authentication.aspx
It sheds some light on why this is the case and provides a somewhat limited workaround. Might work for you or put you on the right track.