Section 13 – Implement Access Management for Apps – Implement app registrations – Set-AzWebApp -name "Anything Microsoft and other stuff on the side"

Five steps for integrating all your apps with Azure AD | Microsoft Docs

Getting to the end, slowly but surely. In this section covering the following:

plan your line of business application registration strategy
implement application registrations
configure application permissions
implement application authorization
plan and configure multi-tier application permissions

Table of Contents

What is App registration in Azure?

With App registration You can register any application to Your tenant and provide authentication and authorization for that application.

When you create an application, you allow trust to be established between the application and the Microsoft identity platform. This trust is only unidirectional, the application trusts Microsoft platform but Microsoft platform doesn’t trust the app.

Plan your line of business application registration strategy

Why do applications integrate with Azure AD?

Add applications to Azure AD to leverage one or more of the services it provides, including:

Application authentication and authorization.
User authentication and authorization.
Single sign-on (SSO) using federation or password.
User provisioning and synchronization.
Role-based access control: Use the directory to define application roles to perform role-based authorization checks in an application.
OAuth authorization services: Used by Microsoft 365 and other Microsoft applications to authorize access to APIs/resources.
Application publishing and proxy: Publish an application from a private network to the internet.
Directory schema extension attributes: Extend the schema of service principal and user objects to store additional data in Azure AD.

Who can sign in to your app?

What are service principals and where do they come from?

You can manage service principals in the Azure portal through the Enterprise Applications experience. Service principals govern an application connecting to Azure AD and can be considered the instance of the application in your directory. Any given application can have at most one application object (which is registered in a “home” directory) and one or more service principal objects representing instances of the application in every directory in which it acts.

What are application objects and where do they come from?

You can manage application objects in the Azure portal through the App Registrations experience. Application objects define and describe the application to Azure AD, enabling Azure AD to know how to issue tokens to the application based on its settings. The application object will only exist in its home directory, even if it’s a multi-tenant application supporting service principals in other directories.

Prerequisites

An Azure account that has an active subscription. Create an account for free.
The Azure account must have permission to manage applications in Azure Active Directory (Azure AD). Any of the following Azure AD roles include the required permissions:

Licensing

Free and basic Azure AD pricing tiers allow You to register 10 applications.

Azure AD Premium 1 and 2 allows registering unlimited apps per user.

Tenants to choose from

The app can be registered inside Azure AD and You have the tenant options.

Work and school (Azure AD) accounts or Microsoft accounts (such as Outlook.com and Live.com)
Social and local (Azure AD B2C) accounts

Limitations

A maximum of 100 users and service principals can be owners of a single application.
A user, group, or service principal can have a maximum of 1,500 app role assignments. The limitation is on the service principal, user, or group across all app roles and not on the number of assignments on a single app role.
An app configured for password-based single sign-on can have a maximum of 48 groups assigned with credentials configured.
A user can have credentials configured for a maximum of 48 apps using password-based single sign-on. This limit only applies for credentials configured when the user is directly assigned the app, not when the user is a member of a group which is assigned.
A maximum of 1,200 entries can be added to the application manifest.

Validation differences by supported account types

When registering an application with the Microsoft identity platform for developers, you’re asked to select which account types your application supports. In the application object and manifest, this property is signInAudience.

The options include the following values:

AzureADMyOrg: Only accounts in the organizational directory where the app is registered (single-tenant).
AzureADMultipleOrgs: Accounts in any organizational directory (multi-tenant).
AzureADandPersonalMicrosoftAccount: Accounts in any organizational directory (multi-tenant) and personal Microsoft accounts (for example, Skype, Xbox, and Outlook.com)

Validation differences for different property’s

Property	AzureAD MyOrg	AzureAD Multiple Orgs	AzureAD PersonalMicrosoftAccount and Personal MicrosoftAccount
Application ID URI (`identifierURIs`)	Must be unique in the tenant urn:// schemes are supported Wildcards aren’t supported Query strings and fragments are supported Maximum length of 255 characters No limit* on number of identifierURIs	Must be globally unique urn:// schemes are supported Wildcards aren’t supported Query strings and fragments are supported Maximum length of 255 characters No limit* on number of identifierURIs	Must be globally unique urn:// schemes aren’t supported Wildcards, fragments, and query strings aren’t supported Maximum length of 120 characters Maximum of 50 identifierURIs
Certificates (`keyCredentials`)	Symmetric signing key	Symmetric signing key	Encryption and asymmetric signing key
Client secrets (`passwordCredentials`)	No limit*	No limit*	If liveSDK is enabled: Maximum of two client secrets
Redirect URIs (`replyURLs`)	See Redirect URI/reply URL restrictions and limitations for more info.
API permissions (`requiredResourceAccess`)	No more than 50 APIs (resource apps) from the same tenant as the application, no more than 10 APIs from other tenants, and no more than 400 permissions total across all APIs.	No more than 50 APIs (resource apps) from the same tenant as the application, no more than 10 APIs from other tenants, and no more than 400 permissions total across all APIs.	Maximum of 50 resources per application and 30 permissions per resource (for example, Microsoft Graph). Total limit of 200 per application (resources x permissions).
Scopes defined by this API (`oauth2Permissions`)	Maximum scope name length of 120 characters No limit* on the number of scopes defined	Maximum scope name length of 120 characters No limit* on the number of scopes defined	Maximum scope name length of 40 characters Maximum of 100 scopes defined
Authorized client applications (`preAuthorizedApplications`)	No limit*	No limit*	Total maximum of 500 Maximum of 100 client apps defined Maximum of 30 scopes defined per client
appRoles	Supported No limit*	Supported No limit*	Not supported
Front-channel logout URL	https://localhost is allowed `http` scheme isn’t allowed Maximum length of 255 characters	https://localhost is allowed `http` scheme isn’t allowed Maximum length of 255 characters	https://localhost is allowed, http://localhost fails `http` scheme isn’t allowed Maximum length of 255 characters Wildcards aren’t supported
Display name	Maximum length of 120 characters	Maximum length of 120 characters	Maximum length of 90 characters
Tags	Individual tag size must be between 1 and 256 characters (inclusive) No whitespaces or duplicate tags allowed No limit* on number of tags	Individual tag size must be between 1 and 256 characters (inclusive) No whitespaces or duplicate tags allowed No limit* on number of tags	Individual tag size must be between 1 and 256 characters (inclusive) No whitespaces or duplicate tags allowed No limit* on number of tags

Implement application registrations

Search for App registration

In this page You can register the application or show Your own endpoints that can be used for connecting to Your published applications.

When You create an application You can choose from different options.

These are supported account types that You can use. If You want to publish the app to Your own users, choose “In this directory only” and if You want to allow any external users, select “Any organizational directory.

Supported account types	Description
Accounts in this organizational directory only	Select this option if you’re building an application for use only by users (or guests) in your tenant. Often called a line-of-business (LOB) application, this app is a single-tenant application in the Microsoft identity platform.
Accounts in any organizational directory	Select this option if you want users in any Azure Active Directory (Azure AD) tenant to be able to use your application. This option is appropriate if, for example, you’re building a software-as-a-service (SaaS) application that you intend to provide to multiple organizations. This type of app is known as a multitenant application in the Microsoft identity platform.
Accounts in any organizational directory and personal Microsoft accounts	Select this option to target the widest set of customers. By selecting this option, you’re registering a multitenant application that can also support users who have personal Microsoft accounts.
Personal Microsoft accounts	Select this option if you’re building an application only for users who have personal Microsoft accounts. Personal Microsoft accounts include Skype, Xbox, Live, and Hotmail

Redirect URI

A redirect URI is the location where the Microsoft identity platform redirects a user’s client and sends security tokens after authentication.

In a production web application, for example, the redirect URI is often a public endpoint where your app is running, like https://cloudpartnerdemo.fi/auth-response. During development, it’s common to also add the endpoint where you run your app locally, like https://127.0.0.1/auth-response or http://localhost/auth-response.

So now You app could look like this.

Configure application permissions

App scope

In the Expose and API You can add permissions for the application.

Application ID URI

The App ID URI acts as the prefix for the scopes you’ll reference in your API’s code, and it must be globally unique. You can use the default value provided, which is in the form api://<application-client-id>, or specify a more readable URI like https://cloudpartnerdemo.fi/api.

Add a scope

From add a scope You can add permissions and who can consent to the permissions. Default is Admin only.

Once created, the scope will show in the page.

Client app

Next You will create a Client Demo app, This app will connect to the DemoApp we created in the earlier steps.

Then API permissions and Add a permissions

Go to My APIs to find the API we created in the earlier steps.

And You will see the Exposed permissions we created.

But You will see there is no consent for the app, click Grant admin consent

And select yes

ut if You don’t have Admin rights the Grant admin consent button is disabled if you aren’t an admin or if no permissions have been configured for the application. If you have permissions that have been granted but not yet configured, the admin consent button prompts you to handle these permissions. You can add them to configured permissions or remove them.

Platforms

Depending on the platform or device this application is targeting, additional configuration may be required such as redirect URIs, specific authentication settings, or fields specific to the platform.

Platform	Configuration settings
Web	Enter a Redirect URI for your app. This URI is the location where the Microsoft identity platform redirects a user’s client and sends security tokens after authentication. Select this platform for standard web applications that run on a server.
Single-page application	Enter a Redirect URI for your app. This URI is the location where the Microsoft identity platform redirects a user’s client and sends security tokens after authentication. Select this platform if you’re building a client-side web app by using JavaScript or a framework like Angular, Vue.js, React.js, or Blazor WebAssembly.
iOS / macOS	Enter the app Bundle ID. Find it in Build Settings or in Xcode in Info.plist. A redirect URI is generated for you when you specify a Bundle ID.
Android	Enter the app Package name. Find it in the AndroidManifest.xml file. Also generate and enter the Signature hash. A redirect URI is generated for you when you specify these settings.
Mobile and desktop applications	Select one of the Suggested redirect URIs. Or specify a Custom redirect URI. For desktop applications using embedded browser, we recommend `https://login.microsoftonline.com/common/oauth2/nativeclient` For desktop applications using system browser, we recommend `http://localhost` Select this platform for mobile applications that aren’t using the latest Microsoft Authentication Library (MSAL) or aren’t using a broker. Also select this platform for desktop applications.

Microsoft Graph

If You go browse App a permission again, You will see lot’s of different APIs. From here You could add permissions for Microsoft Graph.

You have to options to add permissions.

Implement application authorization

Manifest

You can see the config that we just created in the manifest as JSON. You can download, edit it and upload to a different App or just as backup.

What is a Manifest?

With manifest you can manipulate the attributes sent to destination app. There is a json-file that you can edit.

NewGuid

But first you need and Unique GUID, doesn’t have to be anything considering your app, just unique.

You can create a unique GUID with powershell

[guid]::NewGuid()

or if you prefer to use GUID generator from the web, just search, there is a lot of them.

So, GUID looks like this.

App registrations

And every single time you generate new it will be different. Then you go to Azure Active Directory and choose App registrations.

And your freshly configured app.

And Manifest.

Under manifest you find the json file, I like to edit json’s in Visual Studio Code as you lot’s of plugins to provide the necessary support for whatever you are editing.

If you mess up your json, there is no turning back so download it first so you have an backup.

AppRoles

Copy paste to Visual Studio and find the part that says AppRoles

In the AppRoles copy one block and modify based on your needs.

In my demo I created a role called Demo_Role and here is the part you need the Unique GUID

And also add your wanted role to Value field like above.

Then copy paste the json back to online editor and save. If the modification are correct, you will get a popup saying

AppRoles from GUI

When you open App registration, you will find App roles under it.

Allowed member types specifies whether this app role can be assigned to users and groups by setting to ‘User/Groups’, or to other applications by setting to ‘Application’, or to both.

Value specifies which will be included in the “roles” claim of a token identifying a user or app which has been granted this app role

You can easily find the different values for the app roles from Microsoft Graph.

For Delegated permissions

For Application permissions

Assign roles and users

Then go backup Enterprise applications and find your app.

And choose Assign user and Roles.

Choose Add user / Group and find the user or group that you need to assign the app role.

Note! Nested groups cannot be used, but dynamic groups will work.

Certificates or secrets?

You can use a certificates, client secret or Federated credentials (OpenID Connect)

I will go with secrets. You can create secret which will last up-to 24months but Microsoft recommends the maximum to be 12months.

Now is the only time You can copy the secret You just created, after this one it isn’t possible.

Application and object ID

In the overview page You can find Your App and Object ID’s, these are the one that Your software will connect to the apps.

Customizing App

In the Branding & properties You can find the logo and name that will be provided in the MyApps portal and External Azure Enterprise Applications collection.

You can also update Your custom domain here, if any and add Publisher verification.

Publisher verification has to be the Microsoft Partner Network ID that have the same domain than the Custom Domain in the Publisher domain has.

Plan and configure multi-tier application permissions

Multi-tenant app means that user logon to https://login.microsoftonline.com and not to a specific Tenant.

With a multi-tenant application, the application doesn’t know up front what tenant the user is from, so you can’t send requests to a tenant’s endpoint. Instead, requests are sent to an endpoint that multiplexes across all Azure AD tenants: https://login.microsoftonline.com/common

When the Microsoft identity platform receives a request on the /common endpoint, it signs the user in and, as a consequence, discovers which tenant the user is from. The /common endpoint works with all of the authentication protocols supported by the Azure AD: OpenID Connect, OAuth 2.0, SAML 2.0, and WS-Federation.

The sign-in response to the application then contains a token representing the user. The issuer value in the token tells an application what tenant the user is from. When a response returns from the /common endpoint, the issuer value in the token corresponds to the user’s tenant.

When You create a multi-tenant app, you simply choose Multitenant from the app registration.

When the app is created, you can still change the type from here.

On-Behalf-Of flow (OBO)

OAuth 2.0 On-Behalf-Of-Flow (OBO) provides a use case where an application needs to call a service / Web API and then another service / Web API. The idea is to propagate the delegated user ID and permissions to the request chain. In order for the middle tier service to send authenticated requests to downstream services, it must protect the access token from the Microsoft ID platform on behalf of the user.

The client application makes a request to API A with token A (with an aud claim of API A).
API A authenticates to the Microsoft identity platform token issuance endpoint and requests a token to access API B.
The Microsoft identity platform token issuance endpoint validates API A’s credentials along with token A and issues the access token for API B (token B) to API A.
Token B is set by API A in the authorization header of the request to API B.
Data from the secured resource is returned by API B to API A, then to the client.

Things to remember

Free and Basic Azure offers have a limit of 10 apps per user. Azure P1 and P2 don’t have any limit.

Web API has Exposed API and the client have API permissions.

Differences between Application and Object ID:

An app registration in Azure AD results in an Application object. All objects in Azure AD have an object ID. When you making an API request to address a specific Application object, you would use the object ID:

An Application object’s object ID is only relevant in the same tenant where the app is registered, and is only ever used to identify that object.

AppRoles can be defined in Manifest or thru the portal.

An Application objects Application ID attribute is used used across tenants, and on more than one object type. There are two primary uses:

To identify the app in various sign-in and token flows (e.g. client_id in OAuth 2.0 and OpenID Connect).
To uniquely identify the backing Application object of a ServicePrincipal object. (Think of the ServicePrincipal object as the “instance” of the app in a given Azure AD tenant.)

Limitations

A maximum of 100 users and service principals can be owners of a single application.
A user, group, or service principal can have a maximum of 1,500 app role assignments. The limitation is on the service principal, user, or group across all app roles and not on the number of assignments on a single app role.
An app configured for password-based single sign-on can have a maximum of 48 groups assigned with credentials configured.
A user can have credentials configured for a maximum of 48 apps using password-based single sign-on. This limit only applies for credentials configured when the user is directly assigned the app, not when the user is a member of a group which is assigned.
A maximum of 1,200 entries can be added to the application manifest.

Different platform options.

Multi-tenant app logins the user to https://login.microsoftonline.com and the requests go to https://login.microsoftonline.com/common

Understand the different Microsoft identity platform concepts. https://docs.microsoft.com/en-us/azure/active-directory/develop/developer-glossary

Link to main post

SC-300 exam preparation series

Can’t stop learning, in parallel to AZ-500 I will start SC-300 study guide. Enjoy! The Sections There are multiple different sections in the exam, I wrote them more clearly below than in Microsoft Learn site. The sections are based on Microsoft update exam outline for January 28th 2022 Download skills outline from Microsoft Learn Implement an […]