Understanding identity federation and application management in Azure AD

Information technology applications are moving to the public cloud. We call this SaaS software as a service, that rely on a multi-tenancy architecture and provide the same instance of a software to multiple customers or users. For example Microsoft Office 365, or the Adobe Cloud.

Now identity provisioning and life cycle management can be a challenge across numerous applications. This is were federation is a term, to connect and use your Microsoft tenant as IdP (identity provider). SSO, single-sign-on describes the capability of using a single identity (or basically credentials) to several independent systems or software.

Definitions

• Active directory (on-prem) is a server-based directory product.

  • Kerberos - authentication service within active directory
  • LDAP - lightweight directory access protocol

• Azure Active Directory is the modern identity provider in the Microsoft cloud.

• OpenID Connect (OICD) - authentication layer in web

• OAuth 2.0 - authorization protocol

• SCIM - system for cross-domain identity management and offers an open standard for user identity information exchange

Azure Active Directory is not Active Directory in the cloud.

You can see a typical modern architecture, that is all about application and identity management. On-premises there is an Active Directory server and an Azure AD connect for synchronization purposes represented. Then there is your organization's Microsoft tenant, that holds your Azure AD plus all products and services, such as Office 365, Intune or Sentinel. Next to it there are Enterprise Applications and App Registrations as an interface to SaaS apps. The Internet or cloud constitutes of any public cloud application, for example GCP, AWS or just another Microsoft tenant. This doesn't necessary have to be another IdP, it's generally just some kind of product or service discovered in the world wide web.

Enterprise Applications

So an Enterprise Application is basically a local service principal or instance of an application object (App Registration) created by another organization. You can use these in your organization and find them in the Azure AD gallery.

App registrations

In difference to an Enterprise Application, app registrations are fully created and configured in your own tenant by your organization. Those are the global definition of an application.

Source

Create an Enterprise Application

Add an Enterprise Application to your tenant is a fairly simple task. But there are two ways that you can differentiate: the first one would be, to choose the built-in option "continue with Microsoft" in the login page. I am sure that you have seen this before, otherwise scroll down to see a typical consent flow. The second way is to register an Enterprise Application manually. You can do this in the Azure portal under Azure Active Directory and then Enterprise Applications. When creating this instance, you will get some recommendations for gallery apps that were already incorporated with Microsofts identity platform.

After selecting one of the gallery it will look something like this:

So the main focus with these third-party software is to establish SSO. I would always suggest you to take a look at the app documentation on implemenation with Azure AD. The variants to get this done are SAML (security assertion markup language) or some type of password caching.

You can add users and groups that are permitted to use this app.

Create an App registration

To register an app go to the Azure portal and login with sufficient permissions. Navigate to Azure Active Directory, then App registration and create a new registration. You now have 3 options to choose from. Either you only allow users of your tenant to sign-in or you provide a multi tenancy app for B2B or personal Microsoft accounts in a B2C scenario.

After the creation we see some basic information, about the app, like a unique object ID and application ID.

App registrations can also work with claims (which act as user permissions that where delivered in the login request).

The manifest offers the app in JSON form to adjust all the configuration available.

---

Consents

So consents are API-permissions within an enterprise application or app registration instance in your tenant. Usually with a third-party app, the user is going to request this consent. Later on an admin can give the consent for the organization and the user can use SSO. Simply put this is the same as we have seen in the creation of an app registration.

Consent flow

In these modern days we often see a "continue with Microsoft" button in SaaS apps. Behind the scenes this is basic OAuth2 and OpenID Connect, that uses another IdP (Identity Provider) to collaborate and use a federated identity.

The request is then beeing redirected to a Microsoft login page to serve as identity provider.

If the user has enough rights in Azure (e.g. Application Administrator) the user will be able to give this consent directly. Otherwise there is the option to leave an approval request with justification, that an admin will need to approve. Some of the basic permissions don't need any elevated approval.

At this point an enterprise application will be registered in your tenant.

To manage the user consent permissions and API settings in your tenant, direct to Azure Active Directory, then Enterprise Applications and move to Consent and permissions. The contents in the screenshots contain the Microsoft recommended settings that are set by default. Additionally you could add some API permissions that only have "low risk" and can be granted by a common user to any third-party app.