4
votes

My relying party application uses Windows Azure ACS for user Authentication. I have ACS configured to use Windows Azure Active Directory (WAAD) as an identity provider. This is working for the most part and users can sign into my application using identities I have provisioned for them in WAAD. However, the problem I have is that if a user is signed into another Microsoft account, and in the same browser instance tries to sign into my application they get an ugly ACS error "ACS20012: The request is not a valid WS-Federation protocol message". For example, if I open Chrome and sign into the Windows Azure Management Portal using my Windows Live Id, and then open a new tab and try to sign into my custom app I will get that error. If I open a new browser or clear my cookies I can sign in just fine.

Shouldn't I be able to sign into both apps in the same browser instance?

1

1 Answers

4
votes

Nope.

This is to ask to be signed into two Google Accounts (or two Live ID, or whatever two accounts) in the same browser's instance (which actually might be possible using Chrome, but the general case is NO). This is simply impossible today.

It is however ugly to see that error message in the ACS site. Have you configured an ERROR URL for your relying party application in the ACS? Although this property is optional, I strongly advice customers to actually use it, and properly handle requests to it. I haven't tried your particular scenario, but I assume ACS will redirect the user to the Error Url, once you configure it, so you at least know what happens.

Please configure the Error Url for your Relying Party and let us know whether user will be redirected to your site. You shall be then able to generate some proper error message.

UPDATE

If you say this only happens when you are logged-in the Azure management portal, than this (my speculation!) is almost same as sign-in with WAAD. Since the GA of WAAD there had been some changes. If you follow the actual login flow with Fiddler, you will notice that when sign-in to management portal has a bit different flow, then sign-in to Hotmail for instance. If you sign-in to Hotmail, you are just redirected to login.live.com you login and head back to Hotmail.

Now if you inspect the traffic when navigating to manage.windowsazure.com you will notice that there is a first redirect to login.microsoftonline.com (this is WAAD handled!). Then there is redirect to login.live.com (this is for your Live ID account). My speculation here is that WAAD from login.microsoftonline.com federates Live ID (login.live.com) for authentication. That's why you are actually logged in with WAAD, and that's why your app fails.

Please perform the following experiment to confirm whether I am wrong or not:

  1. Delete all your browser's cookies
  2. Go to Hotmail and login with your Live ID account
  3. Now open new tab and open your custom application that federates WAAD via ACS

I suspect that now you will be able to login to your application.