Lets follow, in essence, the steps for enabling an “azure mobile site” to access the directory port of the IDP whose web-sso processes were used, in combination with an oauth handshake, to authenticate users to the app code running on a device. That is, having succeeded to connect the windows store app (running on PC) to its supporting server (node.js scripts, hosted in a windows mobile site), lets make either the app or the site access the directory port. Direct access or indirect access, the accessing party needs creden tials and tokens to pass the directory guards.
Let’s work to make the default app’s UI do better than show only the “minimal” identity indicated above, by accessing tbe directory as above.
See http://www.acupofcode.com/2014/01/accessing-aad-graph-information-from-azure-mobile-services/. Though the post is old, requiring we guess at equivalent steps for the current windows azure console UI, note the objective: take server-side identity and access tokens already bound to the login session shown above and obtain one or more additional access tokens from the IDP/STS COMPONENT of the Azure AD tenant – whose IDP component just challenged the user’s while authorizing the current session.
As we see above, we have modified the service principal (SP pointing) record using the console for the (user) IDP’s directory. This configures the OAUTH authorization component of said directory (and the associated IDP/ FP components, doing the related websso flow management for this “oauth consumer”). The SP is the node.js azure mobile site itself.
Per the instructions, we configured the SP record in the IDP to induce it to issue tokens whose role claims associate an “application scope” to a agent that will assert that now- issued token to the directory port. Furthermore, to get such tokens we saw that such code – the node.js site recall – will need to swap a clientID and associated keyed-password token for it (using the oauth client-credentials grant request)
At this point, our new SP record looks like this:
My guess, from the product manager’s blog post, is that a custom API component – once hosted in the mobile website – will first do the client_credentials token swap, and then use the swapped token to access the directory port.
This makes more sense when you read the rest of the blog post which gives the node.js code for the entire custom api-exposing component, which happens to have an built-in originating-httpClient-UA that talks to the token issuing endpoint (authenticating itself with the shared key, fixed up within the component’s code).
We do get a coherent API-exposing component, hosted in the mobile site:
Our windows store app is updated to use the latest version of the mobile SDK so that the hookup with the ACS-component of AAD works with AAD-implemented IDPs – in addition to working with Google, Twitter and co.
Using the blog post as a hint, we modify the authenticateAsync event handler FROM
to code – running in a store app – whose own embedded http client-UA makes a call to the new custom API component, invoking the remote site-hosted API-method: getIdentities.
Running this we get (after webSSO user dialogs challenging the user using custom domain identifiers):
Fiddler shows that the embedded client did attempt to talk to the custom API – which presumably did some work of its own, talking client-credentials and directory access:
Ok. fix a bug – since we have learned that the getIdentities reference in code invoking the custom API requires that the custom API script is similarly named. (we renamed the reference to match our script name..)
But, after an hour or two’s debugging we cannot actually make the server-side client_credentials handshake work with the token issuing endpoint. It only partly work when we implement the same handshake in the store app code (so we can see ACS-generated) errors.
Clearly the STS does not recognize our client_id, or the client_id cannot be used with THAT resource AND a client_credentials grant.