Update To Partial Authentication System

I’ve posted an improvement to the Partial Authentication System originally posted at Secure Persistent ASP.NET Forms Authentication.

I discovered a problem in the automatic redirection of requests back to HTTP from HTTPS using the requiresSSL=”None” setting in the authorization section. Since most sites would set this to none for their root folder, this caused a problem with the links generated by ASP.NET and AJAX to WebResource.axd and ScriptResource.axd, which are logically (not physically) located in the root of the web application. If you have a secure page in another folder which requests these resources, they were being redirected back to an insecure connection, causing a potential security flaw and causing Firefox to display warnings about partial security.

This has been addressed by ignoring the requiresSSL=”None” setting for a request for any file with the “.axd” extension, effectively treating it as requiresSSL=”Optional” instead. Note that requiresSSL=”Required” is still enforced as normal for files with this extension.

I’ve posted new source and binaries for download.

UPDATE: Please see updated version here

SQL Server 2005 Service Broker Error 15517

Sometimes I’ve run into the following error in the event log when using the service broker to do SQL command notifications with SQL 2005:

An exception occurred while enqueueing a message in the target queue. Error: 15517, State: 1. Cannot execute as the database principal because the principal “dbo” does not exist, this type of principal cannot be impersonated, or you do not have permission.

It tends to fill up the event log pretty badly when you see it. I’ve especially seen it when I move the database from one server to another. To fix it, use this command:


This should fix it for you.

Secure Persistent ASP.NET Forms Authentication

While the ASP.NET Forms Authentication system is a great system for authentication, it has one significant shortcoming for a lot of sites. You can either only restrict it to always pass the authentication cookies in a secure manner or always pass them even if the connection is not secure. There is no intermediate method of authentication available to you. This means that if you are operating a web store you have a problem.

Normally, a web store wants the customer identified as soon as they come to the site, and throughout the shopping experience. However, when the user goes to edit their account or checkout, you want to switch them to a secure mode. In order to be secure, the cookie used to authenticate them for checkout must be restricted to SSL connections. This means that to maintain their login, you would have to remain in SSL from the moment they sign in forward, which adds a lot of unnecessary server load. Plus, it can cause headaches with external content you might want to include on your page that isn’t encrypted.

The solution is to modify the forms authentication system to use a pair of cookies. One is valid only to identify you but not access secure functions, doesn’t require SSL to be transmitted, and is persistent across sessions. The other is a full authentication and requires SSL to be transmitted.

The basic method this system uses is adding two additional HttpModules to your web.config file, PartialAuthenticationModule and PartialAuthorizationModule.

The PartialAuthenticationModule works by adding to the existing FormsAuthenticationModule. The FormsAuthenticationModule is used as normal to process authentication for the secure authentication cookie (requireSSL should be set to true for the forms module in web.config). The PartialAuthenticationModule kicks in after the FormsAuthenticationModule. If there is no user on the current request (i.e. not a secure request, so client didn’t transmit the cookie) then the user is added to the context from the secondary insecure cookie instead. The user that is added will have the “Partial” AuthenticationType instead of “Forms”. In case the login has changed, it will also clear the old secondary cookie if the username doesn’t match with the secure cookie.

The PartialAuthorizationModule processes later in the request life cycle. It uses the section of the section of your web.config files to identify security requirements on each folder. You just add a web.config file to each subfolder as required. This section supports two key fields. requiresLogin is either true or false, and specifies if the folder requires a secure login using the primary FormsAuthentication cookie. It verifies this by checking the AuthenticationType on the logged in user. The second field is requireSSL, which can be None, Optional, or Required. This will automatically redirect the request to or from https based on how you want the folder to be handled. This allows you to use normal app-relative URLs throughout your application without worrying about switching to and from https. Normally, for most folders you would use requiresLogin=”false” and requireSSL=”None”, and for secure folders you would use requiresLogin=”true” and requireSSL=”Required”.

I’ve also implemented a PartialAuthentication static class that is very similar to the FormsAuthentication static class. It actually uses a lot of the methods from the FormsAuthentication class to help it with a lot of the processing. In particular, you should switch any login or logoff code to use the methods in the PartialAuthentication class instead of FormsAuthentication. This will create or remove both of the necessary cookies. To sign off a user from the secure section but still leave the persistent insecure cookie, use the FormsAuthentication.SignOff method instead.

As far as security is concerned, the partial authentication cookie is generated using a FormsAuthenticationTicket just like with FormsAuthentication. It only difference is that the name of the cookie is prepended to the username in the ticket, and on decryption that string is validated. This prevents a client from editing their cookie file to set the secure cookie to have the same value as the insecure cookie. The cookies are encrypted using the same machine authentication keys as the forms authentication tickets, so they should work on web farms in the same manner.

Please note that this library is designed for .NET 3.5 and Visual Studio 2008, though it should be easily
convertible back to .NET 2.0 if you change the project settings.

UPDATE: Please see updated version here

Odd WSHttpBinding Scenario

I was having lots of trouble recently with a WCF WSHttpBinding scenario on a server. It had been working, and the only thing I had changed recently was to the base address of some of the bindings. On top of that, everything was working in my test environment. When I did trace logging on the server, I wasn’t seeing any messages at all other than stating that listening had been started on the correct base addresses. On the client side, I was receiving the following message during the negotiation for the secure session (I’m using message encryption via certificates):

An error occurred while receiving the HTTP response to http://xx.xx.xx.xx:yy/AdvWebClient/CapacityManager. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.

I replaced the ip and port numbers for security purposes.

I worked on this for almost a day, restarting the windows service, changing configuration, staring at trace logs, etc. Finally, as a last ditch effort, I rebooted the server and everything started working. Apparently, there was some kind of hang up in the http.sys that was preventing it from processing the traffic. This is despite the listeners opening and closing (I watched using netstat) when I started and stopped the service.

Hopefully this helps anyone else who encounters this problem. If anyone knows of a way to reset the http.sys system without rebooting the entire computer, please let me know. Thanks.