Installing your line of business application into Azure Active Directory for Single Sign On

Azure Active Directory is Microsoft’s comprehensive Identity as a Service (IDaaS) solution that:

Enables Identity Access Management as a cloud service.
Provides central access management, single-sign on (SSO), and reporting.
Supports integrated access management for thousands of applications in the application gallery, including Salesforce, Google Apps, Box, Concur, and more.

To get started learning about how you can manage applications, see Managing Applications with Azure Active Directory.

Business case for using Azure Active Directory

And you can install your own apps into Azure Active Directory. Registering an application allows any user to do the following:

Get an identity for their application that Azure AD recognizes
Get one or more secrets/keys that the application can use to authenticate itself to AD
Brand the application in the Azure portal with a custom name, logo, etc.
Apply Azure AD authorization features to their app, including:
- Role-Based Access Control (RBAC)
- Azure Active Directory as oAuth authorization server (secure an API exposed by the application)
Declare required permissions necessary for the application to function as expected, including:

You will also be able to:

Configure access rules (such as multi-factor authentication).
Configure the app to require user assignment and assign users (so not everyone needs to have access to the application).
Suppress default user consent experience (which means that a user will not need to sign in over and over just to use your app).

Who can add apps to Azure Active Directory?

Only global administrators can:

Add apps from the Azure AD app gallery (pre-integrated 3rd Party Apps)
Publish an app using the Azure AD Application Proxy

There lots of reasons why this is a great idea. For details, see How and why applications are added to Azure AD.

But if you must prevent users in your directory from adding applications and must prevent users from sharing what information they share with applications, you can change the Directory configuration in the Azure Management portal. In the portal, under Azure Directory, you can configure it to restrict access:

Registering your line of business application

There are a several scenarios you can use to register your custom application. And the details depend on what the type of application is and whether you want to use the v2 endpoints.

There are several pieces in each case:

An identification of your app.
- Sign-on URL. For web applications, you will need a Sign-on URL. This is the base URL for what a user actually signs in. For example, in your development computer, it would be something like http://localhost:12345 ; but when you deploy it, it might be http://myfancyapp.com.
- Redirect URI. For native application, like console applications or mobile apps, use a value that is specific to your application, such as http://mymobileapp. It is just a unique universal resource identified, unique to your application. But it can be just about anything.
Application ID. Once your application is registered, you get back a unique client identification. You will put that into your code.

App Scenarios

By default, the newly created application registration is configured to allow users from your directory (the tenant that you installed the application into) to sign in to your application.

Client apps

Here is how you register your client apps. Use the quick starts, see Azure Active Directory for developers.

Using PowerShell to register your line of business application

First you need to have PowerShell installed for Azure Active Directory. To get started, see Getting started with Azure and Azure Active Directory using PowerShell.

Using the portal to register your line of business application

Then enter App registration information. See Integrating applications with Azure Active Directory.

Consent experience

There are scenarios where your application will need to call a Web API service. See Application Registration.

Next steps

Code

Review how your app is registered and the code used to implement. See the quickstarts, particularly for .Net developers ASP.NET web app sign-in and sign-out with Azure AD.

Complex scenarios

Explore the Authentication Scenarios of Azure AD.

Setting up users, groups, roles

Security tokens issued by Azure AD contain claims, or assertions of information about the subject that has been authenticated. These claims can be used by the application for various tasks. For example, they can be used to validate the token, identify the subject’s directory tenant, display user information, determine the subject’s authorization, and so on.

Once your application is recognized by Azure Active Directory (no matter where it lives on premises, on a mobile device, on AWS, or on Azure), you can then begin to assign permissions.

You can manage users: