PrincipalPermission vs. web.config for page access controls <p>I currently have my access permissions in <code>web.config</code>:</p> <pre><code> &lt;location path="Account"&gt; &lt;system.web&gt; &lt;authorization&gt; &lt;allow users="?"/&gt; &lt;/authorization&gt; &lt;/system.web&gt; &lt;/location&gt; ... </code></pre> <p>I don't like this for two reasons:</p> <ol> <li><code>web.config</code> becomes a mess as my website builds up</li> <li>I'm not sure it's good security to keep the web page access rule so separated from the page itself. After all, I edit aspx/c# files most of the day and not web.config, so things tend to slip.</li> <li>This is a very weird one... I just added ASP.NET4 routing, which changes the URLs. So, all of a sudden my web.config permissions are no longer valid! Similar to point #2 above.</li> </ol> <p>I was thinking it would be better to just use PrincipalPermission as security attributes for the classes/c# files involved in each aspx. My question:</p> <ul> <li>Is this done by anyone, or is it a bad ideas?</li> <li>More importantly... My PrincipalPermission attribute generates an exception (good) but does not redirect users back to the logon page (bad). Can this be fixed?</li> </ul>