Getting BidNow to Work

For the auction at my kid’s school, I volunteered to set up a simple web site to be able to review items available; there is no online bidding at present.  I decided to use the BidNow Azure sample as a base for this, figuring it will also give me a chance to play around a bit with Identity Foundation to enable creating an account on the auction site.

I downloaded the BidNow sample and followed the directions under Getting Started on the home page to install the various required components – this required me to update my Azure tools to the release from the October 2010 PDC (it’s been a while since I’ve played with Azure) and the AppFabric SDK as well as the Identity Foundation SDK and runtime.

There are a set of automated scripts the developers of BidNow have provided to configure things, which is good and bad.  It’s good in that the configuration is somewhat complex and the scripted PowerShell scripts take you through setting it up by asking you a set of questions, TurboTax-style.  It’s bad in that error-handling in the scripts isn’t very robust and so a number of times I encountered stack traces and exception messages from PowerShell which quickly disappeared from my console as the PowerShell scripts blithely continued running, clearing the screen of previous errors before I could even read them.  It’s too bad that PowerShell doesn’t have an easy way of comprehensively logging everything that happened so I could go back and review which steps had failed so I could try to do those manually.  For instance, here is one error I managed to capture:

It’s unclear whether the error is expected since a Yahoo provider didn’t exist, or whether the error occurred trying to set up the ACS.  It’s also unclear whether the scripts are re-runnable or not, and afraid of further screwing up my configuration, I didn’t try that.

Instead, I figured I could figure out whatever steps the scripts missed and just manually do those.  So I built the sample, fired it up and got a home screen – so not all is bad, it could at least connect to the database under local dev fabric and display items.  But when I clicked “log in” the problems started.

The code apparently uses AppFabric Labs identity providers to allow for sign-in across a number of services – Windows Live, Google, Facebook, etc.  That’s great and one reason I picked it.  However, it does this by using some JavaScript to retrieve the identity providers as JSON and then populate the login screen – so debugging why that isn’t working isn’t too straightforwar.  The symptoms are that I just see a “Please Wait” screen when I click login; this is the default HTML for that division on the page, which is replaced by a JavaScript callback when the JSON for the identity providers is delivered.  So apparently it is never getting called back to repopulate the content of that division.

I figured I’d just try the URL the page issues to retrieve the AppFabric Labs identity providers and see what I got.  The URL is something like: (spacing added for readability):

 https://bidnow-sample.accesscontrol.appfabriclabs.com:443/v2/metadata/IdentityProviders.js?
                 protocol=wsfederation&realm=http%3a%2f%2flocalhost%3a8080%2f&
                 reply_to=http%3a%2f%2flocalhost%3a8080%2fLogOn.aspx&version=1.0

It seemed wrong to me that it was referring to the bidnow-sample namespace within AppFabric labs, not the namespace I had created, so I figured that was probably one of the things that didn’t get updated by the scripts.  However, plugging this URL into a web browser, I get this:

Hmm, so it’s not complaining about an invalid namespace, as I’d expect; it’s complaining about the realm (whatever the hell that is) and which appears to point to the Azure local dev fabric.  Looking a bit into what a “realm” is, I find that this is the URI that the issued token from ACS will be valid for.  Searching a bit on the web, I found this page which explains how to set up ACS with Windows Azure.  It explains that when registering the “relying party application” with ACS, you have to specify the URI – I didn’t do that when I set up my AppFabrics lab info.  (This page also has more in-depth information about “relying party applications” and the realm – one of the challenging things about learning any new technology like this is that there are a bunch of new terms which you have to first learn; a good resource here is the December 2010 MSDN article “reintroducing” :) ACS; I guess you have to write an article re-introducing something when the first documentation on this just led to ho-hums and scratching heads.  But this article actually guides you through the necessary steps of configuring the ACS namespace and realm and all up on the AppFabrics Labs web site reasonably well.

Now the MSDN article is concerned with a generic ASP.Net web site, not the Azure BidNow sample, so there’s a bit of reading between the lines here.  After getting you to configure ACS, the MSDN article has you add an STS Reference to your web site.  BidNow already has this configured, so you just have to change the configuration of this.  Open the web.config file in the BidNow.Web project and change the places where it refers to bidnow-sample.accesscontrol… to <namespace>.accesscontrol… where <namespace> is the name of your ACS namespace, created as the MSDN article describes.

You can do this manually, or you can just follow the steps in the article by clicking “Add STS Reference…” to the BidNow.Web project.  The directions in the article are a bit out of date – it seems that some of the UI has changed – but basically, you have to click through, paste in the information from the ACS web site as described (to the “WS-Federation Metadata” URL).  You also have to tell the wizard to generate a certificate for your application – the default of “no encryption” didn’t work for me.

This got me past the first step – when I build and run the app and go to the BidNow home page and click “Login”, I now get a list of providers:

So far, so good.  Clicking on Google takes me to the Google federated login and I am able to login using my GMail account – I am then prompted to share my GMail email address with the ACS – this is as expected and is covered in the article.  However, when I click Approve here, I get this error:

Hmm…  Searching for this error on the web, I find a helpful explanation on acs.codeplex.com:

The rule group(s) associated with the chosen relying party has no rules that are applicable to the claims generated by your identity provider. Configure some rules in a rule group associated with your relying party, or generate passthrough rules using the rule group editor.

OK, so where in the article it told me “just use default rules”, I guess it wasn’t quite right.  Actually, it was – but I missed a step in my haste.  I forgot to click the “Generate Rules” for the default rules group for the providers selected on the ACS portal:

Now you would think that default rules would be, oh, I don’t know, defaulted but apparently not unless you click the button to generate them.  Yup, I’m understanding more and more why they had to write an article re-introducing this service.

After generating these, going back to my dev fabric hosted BidNow, I am able to login!