Question

I run an Azure web role in Full IIS mode. Requests are authorized with custom basic authentication.

I have MyAssembly.CustomIdentity class that inherits from System.Security.Principal.GenericIdentity. When HttpApplication.AuthenticateRequest handler (OnEnter() code from the link above) is invoked it performs checks, then creates an instance of MyIdentity.CustomIdentity and assigns it to HttpContext.Current.User. Then an actual ASP.NET request handler obtains that object and can use it to find what user it is for.

Now everything more or less works fine in default configuration when IIS is running under NETWORK SERVICE account. During role startup I restart IIS application pool under a local user (to grant it extra privileges). Now even the following code

public partial class Default : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        bool isAvailable = Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.IsAvailable;
    }
}

will throw various exceptions. First it says it can’t serialize my CustomIdentity class (which I fix by adding Serializable attribute), then it says it can’t load MyAssembly assembly (which I fix by handling AppDomain.AssemblyResolve event).

What I don’t get is why serialization kicks in? Why running the application pool under s local user and invoking that trivial code suddenly trigger serialization?

Answer 1

Be cautious with this answer, as I am not absolutely sure it is the good one.

First, I assume you haven’t set up something like sql session management, and the only thing you changed is the user under which IIS is running.

You observe two phenomenon:

1. Serialization of an object which shouldn’t be serialized
2. Loading of your assembly by an AppDomain which hasn’t already loaded it.

As your appdomain has already loaded the assembly, it seems safe to assume that the exception is thrown by another AppDomain. If it is thrown by another Appdomain, it’s probably because this AppDomain is attempting to deserialize your custom object. (It has been serialized before the other exception demonstrates that.)

OK. Now even if IIS is running under a local user, Role environnement isn’t. This service is installed with the Azure OS, you can’t choose the user it runs under (you could probably in fact, but I wouldn’t)

What I think is that in order to get informations from RoleEnvironnement, the Azure runtime is able to use two code paths:

1. One if the IIS service and Runtime are running under the same user, which doesn’t require appdomain switching.
2. another if the IIS service and runtime doesn’t share the user they are running under. In this case, the runtime requires it, as the two user doesn’t have the same rights.

To conclude, I certainly don’t know why the Azure runtime would like to move your user between different AppDomain, but it is probably doing exactly that.