{"id":3508,"date":"2016-10-04T10:46:47","date_gmt":"2016-10-04T17:46:47","guid":{"rendered":"http:\/\/www.cloudidentity.com\/blog\/?p=3508"},"modified":"2016-10-04T10:46:47","modified_gmt":"2016-10-04T17:46:47","slug":"provision-an-app-created-on-portal-azure-com-in-your-own-tenant","status":"publish","type":"post","link":"https:\/\/www.cloudidentity.com\/blog\/2016\/10\/04\/provision-an-app-created-on-portal-azure-com-in-your-own-tenant\/","title":{"rendered":"Provision an app created on portal.azure.com in your own tenant"},"content":{"rendered":"

TL;DR: as of today, Azure AD apps created on portal.azure.com won\u2019t be provisioned in your development tenant. This post offers a simple JS form that helps you to do just that.<\/em><\/p>\n

 <\/p>\n

You might recall that a couple of weeks ago Azure AD finally landed on portal.azure.com<\/a>.
\nOne of the key differences you\u2019ll 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.
\nThat means that a number of features, like users and groups assignments, are not available out of the box.<\/p>\n

If you do want to provision the app in your tenant, all you need to do is to \u201ctouch\u201d it, as suggested by the app essentials blade:<\/p>\n

\"image\"<\/a><\/p>\n

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.
\nYou\u2019ll know that the operation succeeded because the essentials blade, once refreshed, will change as in the following:<\/p>\n

\"image\"<\/a><\/p>\n

At this point, all you need to do to manage the app is to click on the link below \u201cmanaged application in local directory\u201d, and you get back all the familiar management features that depend on the presence of a ServicePrincipal for the application.<\/p>\n

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\u2019s not always the case when I develop.<\/p>\n

Here there\u2019s a thought, tho: if you just want to create a ServicePrincipal for your app, you don\u2019t have to implement an entire sign in operation end to end<\/em>: as long as you get past the consent prompt, your ServicePrincipal gets created \u2013 what happens afterwards doesn\u2019t influence that.
\nTo that end, I created a super simple JavaScript snippet that takes in input a tenant, a clientId and a redirect URI \u2013 the ones form the app just created \u2013 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\u2019! The browser will end up giving an error, given that your redirectURL doesn\u2019t have any code listening on it yet \u2013 but your SP will be provisioned.<\/p>\n

Now, if you want to give it a try, I embedded the form in this very post \u2013 you can find it below.<\/p>\n

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\u2019s 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 \u2013 however none of this has been reviewed by our security gurus hence there might be some horrible issue lurking that I am totally missing.<\/p><\/blockquote>\n

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 \u2013> clientID, Reply URL (or Home Page for Essentials) \u2013>redirect URI) and hit the GO! button.
\nRemember, once the consent is done, the browser WILL error out\u2026 that\u2019s expected.<\/p>\n

%CODE%<\/p>\n

 <\/p>\n

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!<\/p>\n

For the more advanced Azure AD developers among you:\u00a0 I can use this little form for experimenting with consent in general \u2013 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.
\nDoes 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<\/a> of the Azure AD book<\/a>, freely available online here<\/a>. Have fun!<\/p>\n","protected":false},"excerpt":{"rendered":"

TL;DR: as of today, Azure AD apps created on portal.azure.com won\u2019t 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\u2019ll…<\/p>\n","protected":false},"author":1,"featured_media":3507,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-3508","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/3508","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/comments?post=3508"}],"version-history":[{"count":2,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/3508\/revisions"}],"predecessor-version":[{"id":3511,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/3508\/revisions\/3511"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/media\/3507"}],"wp:attachment":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/media?parent=3508"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/categories?post=3508"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/tags?post=3508"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}