Using an MSDN-Azure subscription, create an Azure AD instance – alongside an ACS instance/namespace. my AAD is called pingtest1 and the ACS is called homepw. Typically, one authenticates to the Azure portal using a live.com identity, which populates the first administrator.
Add a second administrator, whose identity claim is in the namespace of the AAD instance (Administrator@pingtest1…) in my case.
The goal is now to hook up ACS with AD – by importing the IDPs metadata into the ACS SP. First we add a throwaway “integrated app” (on “https:/localhost/throwaway” URLs) into AAD which exposes all the endpoints:
Then we do the usual ACS screen to the the IDP:
Then we use Visual STudio 2012 to which we have added the identity and access tool (from extensions). To the web form project we add the passive STS, using the wizard (all as conventional). WE selected the ACS option (homepw) which showed us we could bind AAD now to our new RP (to be provisioned in ACS). A login at the App induces a flow to choose an IDP form choises we made as provisioning administrator:
Then we use our temporary password in a screen flow that sets the permanent password. The assertion chain then starts back to our RP:
And this is as far as we can get … until now we use the powershell for AAD to make a service principal (with redirect) for ACS homepw. And that we try next – since now the Administrator@pingtest1.onmicrosoft.com user is evidently well provisioned and fully live.
shows our RP.. and no entry for ACS!
Now according to ACS, for our namespace, our RP endpoint expecting an assertion is
So we change our make serviceprincipal script thus:
We run this in the AAD console (having installed it, yada yada):
We see the final record:
Having generated some claim mapping rules in ACS for this IDP previously, we try a run of the SP again.
It STILL doesn’t work .. as the name presented by ACS is https://…. whereas we were able to register only a name of form homepw/homepw.access…
So, lets try to use the IA tool… spoofing ACS – since this evidently invokes a different means of registering service principals. First we delete the principals we added above.
And this doesn’t work either…
ok. so lets try something else – NOT using the formulaic name form. Lets simply use the (https) of the ACS URL
Hurray. we got from MVC SP to ACS, to Azure AD (to MicrosoftONline Login authentication service) back to ACS and to our MVC App.
You just have to know to make your script behave a bit more like the I&A tool in Visual Studio (not that this worked for me, by itself).
It may or may NOT be relevant that I have added to the list of “integrated apps” using the console