Azure Active Directory Single Sign-On can be used with MVC websites to allow us to create websites with single sign-on authentication for Azure AD users which can be centrally managed in Azure AD.
Visual Studio 2013 makes implementing this really easy and we don't need to touch AD Applications, or web.config in our website.
This article is an extract from a new book I'm writing titled "Learning Microsoft Azure" for Packt Publishing. This website is an admin website for the Sales Business domain of a fictional industrial bakery called Azure Bakery.
I this article, we’re going to create
an Azure Active Directory for the company, then add a user and configure a new MVC5 Administrator website to implement Azure AD Single Sign-On.
Configuring Active Directory
First we need to
create an Active Directory and an initial user account to sign in with
1.
From the
NEW Services menu, select ACTIVE DIRECTORY | DIRECTORY | CUSTOM CREATE:
2.
Fill out
the NAME of the directory, it’s DOMAIN NAME and the COUNTRY OR REGION:
3.
Now from
the Active Directory USERS workspace, click ADD USER from the bottom toolbar to
add a user:
4.
Fill in
the USER NAME. I’ve left TYPE OF USER as New user in your organization,
although you can add an existing Microsoft account or Windows Azure AD
directory:
5.
Next, fill in the user details, select Global
Administrator for the ROLE and click the
next arrow:
6.
Click
create on the next tab to get the temporary password for the user. Make a note
of it and also enter an email to send it to, then click the tick button to
finish:
Configuring an MVC Website for AD Single Sign-On
Next we’ll create a
new MVC website and use the wizard to help us setup AD single sign-on. In
Visual Studio 2012 this was quite tricky to do with a fair amount of manual
configuration in the portal and the website’s web.config, but it’s quite
straight forward in Visual Studio 2013.
1.
In Visual
Studio, add a new ASP.Net Web Application. From the template dialog, select the
MVC template, check Create remote resources under the Windows Azure section and
then click Change Authentication:
2.
Select
Organizational Accounts and enter the AD domain name for the Active Directory
we just created and click OK:
3.
Sign in
using the new Active Directory user, then click OK in the previous dialog (be
careful to change the user to your Azure portal account when prompted to sign
into Azure).
4.
Enter the
Site name, choose Subscription, Region, Database Server (select No database
because we’re using the existing one):
5.
Click OK,
this will now provision the website, setup an AD application and create our MVC
project for us.
6.
We can
test this locally by simply running the website from Visual Studio. You will
get a security warning due to the implementation of a temporary SSL certificate
on your local web server like this (in IE):
7.
Accept the
warning (Continue to this website (not recommended) and you will then see the
AD Login page:
8.
Login with
your new user and the website should load.
Publishing the Website with AD Single Sign-on
When Visual Studio
provisioned our website for us it created an application entry in the AD
APPLICATIONS tab for our local debug configuration:
Rather than changing
the APPLICATION CONFIGURATION for our production website, when we publish the
application, there is an option to Enable Organizational Authentication which
will add a new application entry in AD and rewrite the federation section of
the web.config for us on publish:
<system.identityModel.services>
<federationConfiguration>
<cookieHandler requireSsl="true" />
<wsFederation passiveRedirectEnabled="true" issuer="https://login.windows.net/azurebakery.onmicrosoft.com/wsfed" realm="https://azurebakery.onmicrosoft.com/AdminWebsite" requireHttps="true" />
</federationConfiguration>
</system.identityModel.services>
In the Publish Web
dialog, check Enable Organizational Authentication and enter the AD Domain name.
You will need to include a connection string for your database as the website
will update the database with entries in new IssuingAuthorityKeys and Tenants
tables:
Once published, we
will see a new entry in the AD APPLICATIONS workspace:
This is great as we
don’t need to reconfigure the applications between running locally and
publishing to Azure.
No comments:
Post a Comment