Provision an app created on portal.azure.com in your own tenant
TL;DR: as of today, Azure AD apps created on portal.azure.com won’t be provisioned in your development tenant. This post offers a simple JS form that helps you to do just that.
You might recall that a couple of weeks ago Azure AD finally landed on portal.azure.com.
One of the key differences you’ll encounter when creating Azure AD apps in portal.azure.com lies in the fact that the portal only creates the Application object, but does not actually provision a ServicePrincipal for the app in your development tenant.
That means that a number of features, like users and groups assignments, are not available out of the box.
If you do want to provision the app in your tenant, all you need to do is to “touch” it, as suggested by the app essentials blade:
Essentially, all you need to do is to attempt logging in the application with a user from your development tenant: your user will be prompted for consent, and if you grant it, the app will be provisioned.
You’ll know that the operation succeeded because the essentials blade, once refreshed, will change as in the following:
At this point, all you need to do to manage the app is to click on the link below “managed application in local directory”, and you get back all the familiar management features that depend on the presence of a ServicePrincipal for the application.
Of course the above assumes that you already have your application code already up and running, or at the very least that you have the logic generating an authentication request already configured and in place; and I guess that might not always be the case, or at least that’s not always the case when I develop.
Here there’s a thought, tho: if you just want to create a ServicePrincipal for your app, you don’t have to implement an entire sign in operation end to end: as long as you get past the consent prompt, your ServicePrincipal gets created – what happens afterwards doesn’t influence that.
To that end, I created a super simple JavaScript snippet that takes in input a tenant, a clientId and a redirect URI – the ones form the app just created – creates an authorization code grant request URL from it, and redirects the browser towards it. Here you can sign in with your development tenant user, give consent and.. voila’! The browser will end up giving an error, given that your redirectURL doesn’t have any code listening on it yet – but your SP will be provisioned.
Now, if you want to give it a try, I embedded the form in this very post – you can find it below.
This is a great moment to remind you that this is my personal blog and what you find here is NOT official guidance. I think there’s not much danger here, I am using a code flow for a confidential client because the code is useless without the confidential client credentials anyway, hence the trick I am using here should be fine – however none of this has been reviewed by our security gurus hence there might be some horrible issue lurking that I am totally missing.
All you need to do is to create an app on portal.azure.com as described here, then copy the relevant settings (tenant, Application ID –> clientID, Reply URL (or Home Page for Essentials) –>redirect URI) and hit the GO! button.
Remember, once the consent is done, the browser WILL error out… that’s expected.
%CODE%
Did it work? Head back to portal.azure.com, get to your app and see if the Essentials page changed as described earlier. Ta dah!
For the more advanced Azure AD developers among you: I can use this little form for experimenting with consent in general – for example, for provisioning multitenant apps on an arbitrary tenant, or for manually provisioning resources I need to consent to from clients defined in different tenants, making it impossible to use the knownClientApplications property.
Does that sound like Klingon to you? If you want to learn more about the Azure AD app model, you can take a look at Chapter 8 of the Azure AD book, freely available online here. Have fun!