Problems Deploying a WebRole with Windows Live ID Authentication to the Azure Cloud
• Update 6/30/2009: Microsoft’s Yi-Lun Luo has provided a detailed response to my How to Solve Problem Deploying a WebRole with Windows Live ID Authentication to the Azure Cloud? question of 6/29/2009 in the Windows Azure forum. See the Update 6/30/2009 section at the end of this post for the solution.
•• Update 7/1/2009: The OakLeaf Systems Azure Table Services Test Harness with Windows® Live ID™ Authentication is available to all for testing.
The Windows Live ID Web SDK includes sample code for Default.aspx and webauth_handler.aspx pages that you can use to implement Windows Live ID (WLID) authentication for Azure Hosted Services. My intention was to demonstrate WLID authentication by creating two WLID registrations for the project:
1. A new Live Services: Existing APIs registration with a Return URL pointing to http://localhost:81/webauth-handler.aspx for the Development Fabric:
2. The autogenerated registration (added when creating a new Hosted Service) with a Return URL pointing to http://oakleaf7.cloudapp.net/webauth-handler.aspx:
Note: You can’t remove the Domain value from the autogenerated registration page.
Separate registrations are required for the Development and Cloud Fabrics because you can’t change the domain of the Return URL in either of the two registrations. This is a serious PITA.
The Default.aspx page’s DefaultPage class uses static WindowsLiveLogin wll = new WindowsLiveLogin(true); to specify the registration from wll_appid and wll_secret values in Web.config. You can’t edit Web.config in the Azure Development Portal, so I use the StorageAccountInfo.GetConfigurationSetting() method because IntelliSense says that the method “Gets a configuration setting from application settings in the Web.config or App.config file. When running in a hosted environment, configuration settings are read from .cscfg files.”
Therefore, I created the following Web.config <appSettings> entries for the Development Fabric, which should work fine in the Development Fabric:
And the following ServiceConfiguration.cscfg file with Development Fabric settings which must are replaced with the highlighted production values:
As shown here:
However, a problem with the StorageAccountInfo.GetConfigurationSetting() method causes the Hosted Service to import the wrong wll_appid and wll_secret values (for the Development Fabric registration), as demonstrated in the following sequence.
1. Here’s the correct cloud landing page (http://oakleaf7.cloudapp.net/Default.aspx):
2. Followed by the Windows Live ID sign-in page with the wrong (Development Fabric) app_id in the URL: https://login.live.com/ppsecure/post.srf?appid=0000000044018216&alg=wsignin1.0&appctx=&bk=1246308459
3. And finally, the wrong MainPage.aspx URL with the TargetURL for the Developer Fabric:
The only source of the wrong wll_appid value and http://localhost:81/webauth-handler.aspx URL is the Web.config file. The source code doesn’t contain these values.
The project runs fine in the Development Fabric. MainForm.aspx is a minor modification of the OakLeaf Systems Azure Table Services Sample Project.
My conclusion is that When running in a hosted environment, configuration settings are read from Web.config files. Looks to me like an epic FAIL in the May 2008 CTP.
If anyone on the Azure team wants to take a look at this project and its problems, I’ll be happy to send the source code.
• Update 6/30/2009 based on Yi-Lun Luo’s response to my How to Solve Problem Deploying a WebRole with Windows Live ID Authentication to the Azure Cloud? question of 6/29/2009 in the Windows Azure forum. The problems:
- Substituting the IDLoginStatus control for the WebAuth.htm control in the sample’s IFrame forces all settings to be read from Web.config rather than from Web.config in the Development Fabric and ServiceConfiguration.cscfg in the Azure Fabric.*
- If the ServiceConiguration.csfg file has a value for the requested setting, GetConfigurationSetting() will read it from the ServiceConiguration.csfg file regardless of the operating environment; if the value is missing, GetConfigurationSetting() will read it from the Web.config file.
* As noted in problem #2, IntelliSense’s reported “Gets a configuration setting from application settings in the Web.config or App.config file. When running in a hosted environment, configuration settings are read from .cscfg files” behavior isn’t correct.
Returning to the original IFrame with the WebAuth.htm control solves the URL problem, but doesn’t solve a problem with processing the webauthtoken cookie by the MainForm.aspx page in the cloud.
• Update 7/1/2009 for processing the webauthtoken cookie by the MainForm.aspx page in the cloud.
The MainForm.aspx page isn’t protected from access by unauthenticated users without processing the webauth cookie with code similar to that in the webauth-handler.aspx page:
Note: Logging instructions have been removed from the above example for brevity.
If isLoggedIn = true, code processes remaining Table Storage Test Harness code behind MainPage.aspx. If not, the user is redirected to the Default.aspx page to log in. A user who has previously logged in and whose cookie hasn’t expired will see the logout page upon reentry.
Atom 1.0 site feed
