I have a problem publishing a web app that uses organizational account for authentication. Namely, I chose to publish it on azure website, using new azure SQL database as tenant db. I use Single account and specify .onmicrosoft.com domain.
Step by step:
https://localhost:xxxxx
Where can I configure redirect URL for organizational accounts? I've done for some previous projects Microsoft account authentication, and I know that client id and secret id are bound to a specific return url, but I have no idea where to look for application properties when organizational accounts are used.
Thanks.
Predrag.
To answer my question. Below is one possible workable workflow:
New ASP.NET Project – WebApplication2
a. Select a template: MVC
b. Change Authentication
i. Organizational Accounts
ii. Cloud – Single Organization
iii. Domain: <organization_name>.onmicrosoft.com
iv. Access Level: Single Sign On
c. OK
Configure Microsoft Azure Website
a. Site name: WebApplicationXXXXX
b. Region: North Europe
c. Database server: existing database server
d. Database username: admin
e. Database password: admin_password
f. OK
Publish with the default profile without changing any parameters
a. The result will be Server error in application. In the address bar, it will be http://webapplicationXXXXX.azurewebsites.net/
Browse to https instead of http: https://webapplicationXXXXX.azurewebsites.net/
a. It will be redirected to organizational account correctly. After successful authentication, it will be redirected back to https://localhost:44310/
which is not accessible from Azure website, so it will fail.
Launch publishing again with some corrections this time, Publish Web
a. Connection->DestinationUrl: https://webapplicationXXXXX.azurewebsites.net/
b. Settings->Enable Organizational Authentication (check)
i. Domain: <organization_name>.onmicrosoft.com
ii. Access Level: Single Sign On
c. Publish
It might fail to authenticate first time (no idea why), but when manually browsed to https://webapplicationXXXXX.azurewebsites.net/
, it will work as it is supposed to.
By skipping steps 5 and 6 above, the workflow becomes workable. It’s another question if it’s optimal and according to the best practices.