Folks in the mobile azure program were nice enough to allow me to use a beta feature – that which enables the login process to use the pending Azure AAD features. After completing the basic tasks, we struggled to move onto the more advanced tasks – until today.
I do recommend performing the MANY steps of the following sample:
The steps teach you a lot about the several moving parts in the Azure “security services” platform, force you to correct several of the steps as stated, do a few things not mentioned (but implied), and get you to use the modern Azure AAD directory admin console …to create a SP record in a directory/IDP. If you complete the tasking, you will have obtained a good feel for how a “real” mobile app needs to be coded.
Let me explain things based on the way I got thing to work. So! Having created a database and tied its server channel to the WCF server running in a console window, go to your servicebus relays (in Azure console) – and note that they do exist! This shows that the current server process has indeed tied itself to the azure service bus (which only then exposes these endpoints). This is a good start.
Then remember to fire up the “local data provisioning” client (talking via service bus messaging to the WCF service). This properly populates some data into the sql server’s db!
At this point, we have quite some confidence in the business and data “layers”. Now we focus on the various presentation-layer technologies used to work with the CRUD features, first in an HTML website running in azure websites and then a windows store app running on Windows 8.1.
Our webapp client (of the mobile service feature set) s available (for a few days….) at
After some fiddling, we note that the mobile site API script is able to now talk to the IDP and use the client_credentials grant to obtain tokens sufficient to then consult the directory port. We logged on as firstname.lastname@example.org – using this custom directory tenant that we added to our azure subscriptions.
One gotcha that you have to figure is that the scripting assumes application scoping, so set it!
While our client’s access to the the mobile API script for product data doesn’t work (yet), recall that it is supposed to be accessing the (working) service bus having used ACS to get SWT-era access tokens. We will fix that later (assuming things in ACS land and SB land are sill as the programing assumed, a year ago.) We are happy we can finally read the directory port!
To see things a little more clear, we then repeated the client access exercise, using the windows store project this time
This teaches us a little about using password “Credentials” to store access tokens, keyed off the AAD name of the mobile site. Presumably several apps using the APIs, and when cued of the same AAD id, would be able to get an SSO type experience at store app launch.