Share via

web.config location tag - authentication pitfall

  • Article

Quick intro to the <location> element in config

One of the great features for WCF services is the ability to control settings on resources within a virtual directory on a per-location basis.  The way to do this is with the <location> tag.  If you ever set up authentication schemes in IIS for a vdir, you can see an example of this by looking at the end of the file at \Windows\System32\inetsrv\config\applicationHost.config.  For example:

    <location path="Default Web Site/MyWebSite">
        <system.webServer>
            <security>
                <authentication>
                    <anonymousAuthentication enabled="false" />
                    <windowsAuthentication enabled="true" />
                </authentication>
            </security>
        </system.webServer>
    </location>

 But this leads me to the pitfall: If you try pushing this into your web.config file, the settings won't apply to the host.  This is because the path attribute is relative to where the config file is.  So, if you have two .svc files under the same vdir, and you want them to have two different auth modes, you can do it like this in web.config:

  <location path="EchoService1.svc">

    <system.webServer>

      <security>

        <authentication>

          <windowsAuthentication enabled="true"/>

          <basicAuthentication enabled="false"/>

        </authentication>

      </security>

    </system.webServer>

  </location>

  <location path="EchoService2.svc">

    <system.webServer>

      <security>

        <authentication>

<windowsAuthentication enabled="false"/>

<basicAuthentication enabled="true"/>

        </authentication>

      </security>

    </system.webServer>

  </location>

 But alas, when you try this, you get an activation exception when you try to browse to the site:

This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".

The reason for this is that in applicationHost.config, the authentication sections are locked so that apps can't override them.  You can now either move these location elements to applicationHost.config (and fix the path attribute), or unlock the sections in applicationHost.config.  To unlock the sections, either hand-modify applicationHost.config or use appcmd.exe.