Self hosting in Azure role Pb when swapping the staging and production environments

Jan 8, 2014 at 10:10 AM

My worker role is started with this code

            var endpoint        = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["Endpoint1"];
            string baseUri      = string.Format("{0}://{1}", endpoint.Protocol, endpoint.IPEndpoint);
            endpoint            = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["Endpoint2"];
            string baseSSLUri   = string.Format("{0}://{1}", endpoint.Protocol, endpoint.IPEndpoint);
            Trace.TraceInformation(String.Format("Starting OWIN at {0}/{1}", baseUri,baseSSLUri),"Information");
            var startOpt        = new StartOptions();
            _app                = WebApp.Start<Startup>(startOpt);
Problem is that when I deploy using VS2013 in a staging role, the Enpoint receive an IP attached to the staging environment and when I swap the environement, they Owin keep listening on this IP, but the IP has been swapped....
I can detect RoleEnvironmentChanging concerning RoleEnvironmentTopologyChange, but is there a way to ask Owin listening on the new IPs ?

I actually restart the Role, which is not optimal.
Jan 8, 2014 at 4:25 PM
There is not currently a way to re-configure the listener while it is running.

You do not want to restart the Role because it takes too long to reboot, correct?

How about restarting just the listener by disposing of the _app and calling WebApp.Start again? That should be much faster.
Jan 8, 2014 at 5:28 PM
Edited Jan 8, 2014 at 5:31 PM
Thanks for answer.
In fact I believe that I was misunderstanding the way Azure EndPoint are running when there are several Instances of the same WorkerRole.
Each worker role get an internal azure IP.
The Azure LoadBalancer take care dispatching all the calls targeting the public domain IP to each instance.
So its is normal that each instance don't listen on the same IP.

Swapping from staging to production only change the mapping made by the loadbalancer, each running process still listen on the same IP. No need to 'rehost owin'.

I finally discovered that i have one instance working perfectly when I use authentication Bearer but not the second one.

Using the new aspnet Identity 2.0 with EF, I initialize like this
            OAuthOptions        = new OAuthAuthorizationServerOptions
                TokenEndpointPath           = new PathString("/api/v1/Token"),
                Provider                    = new MyOAuthProvider(PublicClientId),
                AuthorizeEndpointPath       = new PathString("/api/v1/Account/ExternalLogin"),
                AccessTokenExpireTimeSpan   = TimeSpan.FromDays(14),
                AllowInsecureHttp           = true
            app.UseCookieAuthentication(new CookieAuthenticationOptions {
                AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
                LoginPath = new PathString("/api/v1/Account/Login"),
                Provider = new CookieAuthenticationProvider {
                        OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<DatwendoUserManager, DatwendoUser, int>(
                        validateInterval: TimeSpan.FromMinutes(20), 
                        regenerateIdentityCallback: (manager, user) => user.GenerateUserIdentityAsync(manager),


            // Enable the application to use bearer tokens to authenticate users
When I trace I get successful authentication on each WebAPI call on the first Instance, but receive a 401 on the next call distributed on the second instance of my worker role by the loadbalancer ???

My App work perfectly with one role but gain Azure 99.95 SLA waranty we must run 2 instances of each Role....
Jan 8, 2014 at 5:57 PM
Edited Jan 8, 2014 at 6:08 PM
Could it be a problem with the bearer token working only on the Instance which generated it ?
EDIT: in fact the not working instance sucessfully generates a token but is unable to authenticate with it ?
The other instance authenticates with tokens it generates and with tokens from the other ?????
puzzling ?
Jan 8, 2014 at 6:13 PM
That depends on how you generate and validate your tokens. Both machines need access to the same information to generate and validate tokens. If you generate them, store them, and then look them up for validity, then that storage needs to be shared. If you sign them with an encryption context, that context needs to be synced (e.g. Asp.Net's MachineKey feature).
Jan 8, 2014 at 6:59 PM
Edited Jan 8, 2014 at 7:51 PM
No that's not the problem because the instance with problem is unable to use the tokens it generates !!!!
And the other one work with tokens from any instance.
Problem is somewhere in the identity validation in this badly behaving instance.
That's not a pb of MachineKey.

Tokens are generated by the default methods in Identity/owin no special thing added.
Jan 9, 2014 at 7:55 AM
You make me doubt concerning Azure: when using a WebRole the farm scenario is automatically assumed by Azure and machine key is the same on each instance, but is it the same with WebRole.

If I selft Host Owin in a Worker Role, there is there a machine key ? How is working Owin for its Tokens/Tickets in this situation ?
I think the bug is inside Owin authentication and will open a ticket.