{"id":315,"date":"2011-05-31T01:30:00","date_gmt":"2011-05-31T10:30:00","guid":{"rendered":"http:\/\/www.cloudidentity.com\/blog\/2011\/05\/31\/edit-and-apply-new-wifs-config-settings-in-your-windows-azure-webrole-without-redeploying\/"},"modified":"2013-03-14T20:33:31","modified_gmt":"2013-03-15T05:33:31","slug":"edit-and-apply-new-wif-s-config-settings-in-your-windows-azure-webrole-without-redeploying","status":"publish","type":"post","link":"https:\/\/www.cloudidentity.com\/blog\/2011\/05\/31\/edit-and-apply-new-wif-s-config-settings-in-your-windows-azure-webrole-without-redeploying\/","title":{"rendered":"Edit and Apply New WIF\u2019s Config Settings in Your Windows Azure WebRole\u2026 Without Redeploying!"},"content":{"rendered":"

In short: in this post I will show you how you can leverage the OnStart event of a WebRole to enable changing the WIF config settings even after deployment.<\/p>\n

Since the very first time Hervey<\/a> and I made the first foray<\/a> in Windows Azure with WIF, all the way to the latest hands-on labs<\/a>, books<\/a> and whitepapers<\/a>, one of the main challenges of using WIF in a WebRole has always been the impossibility of updating the settings in <microsoft.identityModel><\/strong><\/font> without redeploying (or preparing in advance for a pool of alternative <service><\/font><\/strong> elements fully known at deployment time).<\/p>\n

Last Friday I was chatting with Wade<\/a> about how to solve this very problem for some future deliverables in the toolkit<\/a>, and it just came to me: why don\u2019t we just leverage the WebRole lifecycle and use OnStart<\/strong><\/font> for setting the values we want even before WIF reads the web.config<\/em>? All we need to do is create suitable <setting> entries in the ServiceConfiguration.cfg file, which can be modified without the need to redeploy, and use the events in WebRole.cs to ensure that our apps picks up the new values. Simple!<\/p>\n

I created a new WebRole, hooked it to a local SelfSTS<\/a>, and started playing with ServiceDefinition.csdef<\/strong>, ServiceConfiguration.cscfg <\/strong>and WebRole.cs<\/strong>. I just wanted to make sure the idea works, hence I didn\u2019t pour much care in writing clean (or exhausting) code. Also, I totally ignored all the considerations about HTTPS, NLB session management and all those other things you learned you need to do in WIndows Azure. None of those really interferes with the approach, hence for the sake of simplicity I left them all out.<\/p>\n

First, I created <Setting> entries  in the .csdef for every WIF config parameter generated by the Add STS Reference you\u2019d likely want to control:<\/p>\n

\n
<?<\/span>xml<\/span> version<\/span>="1.0"<\/span> encoding<\/span>="utf-8"<\/span>?><\/span>
<<\/span>ServiceDefinition<\/span> name<\/span>="WindowsAzureProject5"<\/span> xmlns<\/span>="http:\/\/schemas.microsoft.com\/ServiceHosting\/2008\/10\/ServiceDefinition"<\/span>><\/span>
  <<\/span>WebRole<\/span> name<\/span>="WebRole1"<\/span>><\/span>
    <<\/span>Runtime<\/span> executionContext<\/span>="elevated"<\/span> \/><\/span>
    
    <!--... stuff--><\/span>
    <<\/span>ConfigurationSettings<\/span>><\/span>
      <<\/span>Setting<\/span> name<\/span>="audienceUri"<\/span> \/><\/span>
      <<\/span>Setting<\/span> name<\/span>="issuer"<\/span> \/><\/span>
      <<\/span>Setting<\/span> name<\/span>="realm"<\/span> \/><\/span>
      <<\/span>Setting<\/span> name<\/span>="trustedIssuersThumbprint"<\/span> \/><\/span>
      <<\/span>Setting<\/span> name<\/span>="trustedIssuerName"<\/span> \/><\/span>
    <\/<\/span>ConfigurationSettings<\/span>><\/span>
  <\/<\/span>WebRole<\/span>><\/span>
<\/<\/span>ServiceDefinition<\/span>><\/span><\/pre>\n
<\/div>\n
Yes, yes, having settings just for one issuer in the trusted issuers registry is not especially elegant; and adding a homeRealm would probably be useful. Some other time.
\n  
The important thing to notice here is the <Runtime executionContext=elevated\u201d \/><\/font><\/strong>. Without that, you won\u2019t be able to save the modifications to the Web.Config.<\/p>\n
Then I added the same settings in the .cscfg, leaving all the values empty (for now).<\/p>\n
\n
<?<\/span>xml<\/span> version<\/span>="1.0"<\/span> encoding<\/span>="utf-8"<\/span>?><\/span>
<<\/span>ServiceConfiguration<\/span> serviceName<\/span>="WindowsAzureProject5"<\/span> xmlns<\/span>="http:\/\/schemas.microsoft.com\/ServiceHosting\/2008\/10\/ServiceConfiguration"<\/span> osFamily<\/span>="1"<\/span> osVersion<\/span>="*"<\/span>><\/span>
  <<\/span>Role<\/span> name<\/span>="WebRole1"<\/span>><\/span>
    <<\/span>Instances<\/span> count<\/span>="1"<\/span> \/><\/span>
    <<\/span>ConfigurationSettings<\/span>><\/span>
      <<\/span>Setting<\/span> name<\/span>="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString"<\/span> value<\/span>="UseDevelopmentStorage=true"<\/span> \/><\/span>
      <<\/span>Setting<\/span> name<\/span>="audienceUri"<\/span> value<\/span>=""<\/span> \/><\/span>
      <<\/span>Setting<\/span> name<\/span>="issuer"<\/span> value<\/span>=""<\/span> \/><\/span>
      <<\/span>Setting<\/span> name<\/span>="realm"<\/span> value<\/span>=""<\/span> \/><\/span>
      <<\/span>Setting<\/span> name<\/span>="trustedIssuersThumbprint"<\/span> value<\/span>=""<\/span> \/><\/span>
      <<\/span>Setting<\/span> name<\/span>="trustedIssuerName"<\/span> value<\/span>=""<\/span> \/><\/span>
<!--...stuff--><\/span>
    <\/<\/span>ConfigurationSettings<\/span>><\/span>
    <!--...stuff--><\/span>
  <\/<\/span>Role<\/span>><\/span>
<\/<\/span>ServiceConfiguration<\/span>><\/span><\/pre>\n
<\/div>\n
Very straightforward. Then I went ahead and added to WebRole.cs  the code below: <\/p>\n
\n
namespace<\/span> WebRole1
{
    public<\/span> class<\/span> WebRole : RoleEntryPoint
    {
        public<\/span> override<\/span> bool<\/span> OnStart()
        {
            RoleEnvironment.Changing += RoleEnvironmentChanging;

                using<\/span> (var server = new<\/span> ServerManager())
                {
                    var siteNameFromServiceModel = "Web"<\/span>;
                    var siteName =
                        string<\/span>.Format("{0}_{1}"<\/span>, RoleEnvironment.CurrentRoleInstance.Id, siteNameFromServiceModel);

                    string<\/span> configFilePath = server.Sites[siteName].Applications[0].VirtualDirectories[0].PhysicalPath + "\\Web.config"<\/span>;
                    XElement element = XElement.Load(configFilePath);

                    string<\/span> strSetting;

                    if<\/span> (!(String.IsNullOrEmpty(strSetting = RoleEnvironment.GetConfigurationSettingValue("audienceUri"<\/span>))))
                        element.Element("microsoft.identityModel"<\/span>).Element("service"<\/span>).Element("audienceUris"<\/span>).Element("add"<\/span>).Attribute("value"<\/span>).Value = strSetting;
                    if<\/span> (!(String.IsNullOrEmpty(strSetting = RoleEnvironment.GetConfigurationSettingValue("issuer"<\/span>))))
                        element.Element("microsoft.identityModel"<\/span>).Element("service"<\/span>).Element("federatedAuthentication"<\/span>).Element("wsFederation"<\/span>).Attribute("issuer"<\/span>).Value = strSetting;
                    if<\/span> (!(String.IsNullOrEmpty(strSetting = RoleEnvironment.GetConfigurationSettingValue("realm"<\/span>))))
                        element.Element("microsoft.identityModel"<\/span>).Element("service"<\/span>).Element("federatedAuthentication"<\/span>).Element("wsFederation"<\/span>).Attribute("realm"<\/span>).Value = strSetting;
                   
                    if<\/span> (!(String.IsNullOrEmpty(strSetting = RoleEnvironment.GetConfigurationSettingValue("trustedIssuersThumbprint"<\/span>))))
                        element.Element("microsoft.identityModel"<\/span>).Element("service"<\/span>).Element("issuerNameRegistry"<\/span>).Element("trustedIssuers"<\/span>).Element("add"<\/span>).Attribute("thumbprint"<\/span>).Value = strSetting;
                    if<\/span> (!(String.IsNullOrEmpty(strSetting = RoleEnvironment.GetConfigurationSettingValue("trustedIssuerName"<\/span>))))
                        element.Element("microsoft.identityModel"<\/span>).Element("service"<\/span>).Element("issuerNameRegistry"<\/span>).Element("trustedIssuers"<\/span>).Element("add"<\/span>).Attribute("name"<\/span>).Value = strSetting;

                    element.Save(configFilePath);
                }
           
                            
            return<\/span> base<\/span>.OnStart();
        }
        private<\/span> void<\/span> RoleEnvironmentChanging(object<\/span> sender, RoleEnvironmentChangingEventArgs e)
        {
            e.Cancel = true<\/span>;
        }
    }
}<\/pre>\n
<\/div>\n
Let\u2019s look at what happens in the using block first. If you want to read good writeups on this technique I suggest this msdn entry<\/a> or this really nice entry from Andy Cross<\/a>.<\/p>\n
When OnStart runs, the WebRole application itself didn\u2019t have a chance to do anything yet. What I want to do here is getting my hands on the web.config file, override the WIF settings with all the non-empty values I find in ServiceConfiguration.cscfg and save back the file even before WIF gets to read <microsoft.identityModel>.<\/p>\n
What I do above with Linq to XML for modifying the WIF settings is pretty dirty, very brittle and definitely tied to the assumption that the config we\u2019ll be working with is the one that comes out from a typical Add STS Reference run. I tried to use ConfigurationManager at first, but it complained that <microsoft.identityModel> has no schema hence I just went the quicker, easier, more seductive \u201clet\u2019s just see if it works\u201d. But remember, for the one among you who caught the reference: the dark side is not stronger. No no no.<\/p>\n
Aaanyway. The element.Save(configFilePath) <\/strong><\/font>is the line that will fail if you forgot to add the elevated directive in the csdef, you\u2019re warned.<\/p>\n
The RoleEnvironmentChanging<\/strong> handler hookup at the beginning of OnStart, and the handler itself, are meant to ensure that when you change the values in ServiceConfiguration.cscfg Windows Azure will properly restart the role. If you don\u2019t add that, just changing the config will not drive changes in the WebRole behavior until a stop & restart occurs. Technically there are few things you may try to do to get WIF to pick up the new settings at mid flight, but all those would entail changing the application code and that\u2019s exactly what I am trying to avoid with all this brouhaha.<\/p>\n
BTW, you can thank Nick Harris<\/a> for the RoleEnvironment.Changing<\/strong><\/font> trick\"Smile\"<\/p>\n
Nick just joined the Windows Azure Evangelism team and he is already doing an awesome job.<\/p>\n
That should be all. Now, try to ignore the impulse that would make you change the config before deploying, and publish the project in Windows Azure staging \u201cas is\u201d.<\/p>\n
\"image\"<\/a><\/p>\n
In few mins the instance is up and running, listening at a nice (and totally unpredictable) URL http:\/\/eddb883659d04d0bbbb570f17c52ea01.cloudapp.net<\/a>. What do you think will happen if I just navigate there?<\/p>\n
\"image\"<\/a><\/p>\n
That\u2019s right. WIF is still configured for the address the application had in the environment formerly known as devfabric (now Windows Azure simulation environment), as described in the realm entry, hence SelfSTS (which behaves like the WIF STS template if there\u2019s no wreply in the signin message) sends the token back there instead of http:\/\/eddb883659d04d0bbbb570f17c52ea01.cloudapp.net<\/a>. Normally we\u2019d be pretty stuck at this point, but thanks to the modification we made we can fix the situation.<\/p>\n
All you need to do is navigating to the Windows Azure portal, select the deployment and hit the Configure button.<\/p>\n
\"image\"<\/a><\/p>\n
Here you can pick the Edit current configuration option to update the values inline. In this case, all you need to do is pasting http:\/\/eddb883659d04d0bbbb570f17c52ea01.cloudapp.net<\/a> in the audienceUri and realm settings, and hit OK.<\/p>\n
\"image\"<\/a><\/p>\n
You\u2019ll see the portal updating the instance for few moments. As soon as it reports the role as ready, navigate to its URL and, surprise surprise, this time the authentication flow ends up in the right place! In the screenshot below you can see (thanks to the SecurityTokenVisualizerControl, which you can find in all the latest ACS labs in the identity training kit<\/a>) that the audienceURI has been changed as well.<\/p>\n
\"image\"<\/a><\/p>\n
I think that\u2019s pretty cool \"Smile\"<\/p>\n
Now, you may argue that this scenario is an artifact of how the WIF STS template handles things, and if you would have ben dealing with an STS (like ACS) which keeps realm and return URLs well separated you could have solved the matter at the STS side. All true, but beside the point.
\n  
Here I used the staging & realm example because with its unknowable-until-it\u2019s-too-late GUID in the URL it is (was?) the paradigmatic example of what can be challenging when using WIF with Windows Azure; but of course you can use the technique you saw here for pushing out any<\/em> post-deployment changes, including pointing the WebRole to a different STS, updating certificate thumbprints as keys rollover takes place or any other setting you may want to modify.<\/p>\n
Please use this technique with caution. I haven\u2019t used extensively yet hence I am not 100% sure if there are gotchas just waiting to be found, but so far it seems to be solving the problem pretty nicely \"Smile\"<\/p>\n
<\/div>\n","protected":false},"excerpt":{"rendered":"
In short: in this post I will show you how you can leverage the OnStart event of a WebRole to enable changing the WIF config settings even after deployment. Since the very first time Hervey and I made the first foray in Windows Azure with WIF, all the way to the latest hands-on…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"footnotes":""},"categories":[7,8,5,6,4],"tags":[],"class_list":["post-315","post","type-post","status-publish","format-standard","hentry","category-access-control-service","category-acs","category-wif","category-windows-azure","category-windows-identity-foundation"],"_links":{"self":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/315","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/comments?post=315"}],"version-history":[{"count":1,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/315\/revisions"}],"predecessor-version":[{"id":1676,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/315\/revisions\/1676"}],"wp:attachment":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/media?parent=315"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/categories?post=315"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/tags?post=315"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}