# Azure Application Consent

- Link: https://www.agilicus.com/white-papers/azure-application-consent/
- Published: 2020-12-24T14:35:40+00:00
- Author: Don Bowman

1. [Home](https://www.agilicus.com/)
 2. Azure Application Consent

![Azure Application Registration Consent](https://www.agilicus.com/www/5663b320-
azure-application-registration-consent.svg)

## Azure Application Consent

[CONTACT](https://www.agilicus.com/contact-us/)

## Overview

[⌊venn diagram identity⌉⌊venn diagram identity⌉[

The Agilicus AnyX platform uses external Identity Providers (typically Microsoft
Azure, Google Workplace) rather than creating ‘parallel’ identities for users to
remember. This provides increased security and reduced risk for all three constituents(
Agilicus Customer, Customer Partners, and, partner end-users.

This approach to Identity is called Federated Authentication. In this model, each
company manages their own users identity. This includes identity attestation (this
person works for me). This is a normal part of their human resources workflow (new
employee, create entry in Active Directory of Google Workplace), and, includes offboarding(
remove user from Identity Directory). The Agilicus AnyX Customer is able to select
individual users (identities) from each of their Partner’s and then perform a shared
Authentication to prove the identity. This Authentication is performed against the
existing Single-Sign-On system: the end-user sees the same web interface, same username,
same password.

A federated Chain of Trust is built: Customer ‘trusts’ Microsoft Azure to attest
to a user’s Identity. Partner-1 manages the Users. Customer manages which Identities
are allowed to flow across the interface (e.g. it is not allowing ALL users, only
specific ones), and, what actions they can do (Authorisation).

The Customer then allows access to specific resources, for those users, according
to the desired Authorisation.

## Example

Assume there are 3 companies.

 * City of EGov. They operate the Agilicus AnyX platform.
 * MSPco. They are a managed-service provider who performs desktop assistance on
   behalf of many customers, including City of EGov.
 * HVACco. They perform remtoe-maintenance on air-conditioning, building management
   systems.

The City of EGov uses Microsoft Office 365. As a consequence their direct employees
can authenticate (sign-in) to systems with an identity that looks like ‘user@egov.
city’).

MSPco uses Azure Active Directory in their own tenant. As a consequence their direct
employees can authenticate (sign-in) to systems with an identity that looks like‘
user@msp.co’.

HVACco uses Google Workplace. Their direct employees authenticate (sign-in) to systems
with an identity that looks like ‘first.last@hv.ac’.

Assume that the City of EGov has two resources (netwok addressable systems). One
is a remote backup system, it has a web-interface which allows two main functions:
reporting (e.g. checking that each backup has been performed), and, an administrative
function that allows adding new enpoints. The second resource is a Building Management
System, supporting checking of alarms, door locks, temperatures, etc.

Assume these people have these roles:

| Identity | Company | Backup-Report | Backup-Admin | BMS | 
| jane@egov.city | City of Egov | ✓ | ✓ | ✓ | 
| joe@egov.city | City of Egov | ✓ |  |  | 
| sally@msp.co | MSPco | ✓ | ✓ |  | 
| fred@msp.co | MSPco | ✓ |  |  | 
| lisa@hvac.ac | HVACco |  |  | ✓ |

Here we can see that the ‘identity’ (left column) is entirely owned by the company
the user works for.

The authentication (proving that someone is who they say they are) is performed 
by a combination of the company they work with and the City of Egov. The City of
Egov has not linked e.g. ‘edward@msp.co’ or ‘fred@gmail.com’, so they cannot authenticate.

The City of Egov, alone, owns authorisation (e.g. sally@msp.co can both see backup
reports and also add endpoints but cannot use the building management).

![Azure Application Consent Explained: Streamline user access and enhance security
for your Azure applications. Learn how to configure and manage application consent
in Azure Active Directory to ensure secure delegation and control permissions effectively.
Image depicts the Azure application consent workflow.](https://www.agilicus.com/
www/1d98bb5c-image.png)

No shared accounts are present (e.g. there is not a mspco@egov.city account). This
means there is no concern about someone leaving their organisation (e.g. sally leaves
MSPco).

![Azure Application Consent: Streamlining access management and enhancing security
for applications in Azure Active Directory. Visualize the consent flow and understand
how to grant and manage permissions effectively. Learn about the benefits of user
and admin consent, and best practices for securing your Azure applications.](https://
www.agilicus.com/www/d7ed0cf8-image.png)

In this example, each user, on their own device, is challenged with an initial Sign-
In screen similar to at right. When sally@msp.co selects ‘Sign-In with Microsoft’,
she is presented with **HER** normal Azure sign-in. E.g. Sally would see next her
branded screen (something like below). This would in turn force her companies policies
to apply (multi-factor, saved password, etc).

![Azure Application Consent Workflow: Understand how application consent works in
Azure Active Directory, including the roles, permissions, and steps involved in 
granting and managing application access to your Azure resources. Learn about minimizing
security risks and best practices for secure application integration.](https://www.
agilicus.com/www/1b2cee21-image.png)

jane@egov.city would also select ‘sign-in with Azure’. She might see the below screen,
assuming her organisation has not branded the Azure sign-in experience.

In both cases, the user has a single-sign-in experience.

## Consent Flow

![Azure Application Consent Explained: Streamline user access and enhance security
with Agilicus's comprehensive guide to Azure application consent. Understand permissions,
authorization flows, and best practices for managing application access in your 
Azure environment. Visualize the process with a clear diagram illustrating the steps
involved in granting and managing consent for applications.](https://www.agilicus.
com/www/746ba5f6-image.png)

Depending on the configuration of the Azure Active Directory (or ADFS), the first
user of an organisation signing-in might be presented with a ‘Approval required’
message similar to below.

As an Azure administrator, you can control which applications triggers a ‘consent’
flow, and, which users can answer it. For more information see “[Configure how users consent to applications](https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-user-consent)”
in the Azure Product Documentation.

It is important to read the permissions requested. The most basic level (sign-in
and read-profile) is granting permission to:

 1. The requesting system (Agilicus AnyX) can allow shared authentication, can trust
    a sign-in
 2. The requesting system (Agilicus AnyX) can see the user’s First Name, Last Name,
    Email Address

**No permission** is granted to read Active Directory, access Azure or Office 365
resources, etc. This permission is only granted on a valid user signing in (e.g.
no permission is granted on other users, just the one that caused this flow).

The chain of trust is created from the Agilicus Multi-Tenant Application Registration(
which is in the Azure catalog as a verified publisher). Granting the permission 
allows the City of Egov from the example above to authorisation **their own resources**
using the MSP.co Azure Active Directory.

**No permission** exists absent a currently signing-in user (e.g. the Agilicus AnyX
system cannot independently read the user email, nor can it read a different user
email).

The consent can either be granted on the first use (as in the example above), or
via the Azure console pro-actively. If using the Azure console you can grant this
consent on smaller groups of users or groups.

## Benefits

The Federated Identity with shared Authentication provides a set of key security
and usability benefits to each of the three main constituents.

By providing a consistent user-experience on sign-in, it is easier to train users
to phishing attempts. This in turn reduces the risk to each organisation.

By providing a single username/password across all systems, there is reduced risk
of password re-use and sharing, leading to lower risk of breach.

By allowing the Agilicus AnyX customer to enforce authentication policies such as
multi-factor, it can increase their compliance and lower their risk. This in turn
can reduce the cost of Errors & Omissions Cyber Security Insurance.

For the end-user, a single-sign-on experience reduces sign-in-fatigure, simplifying
their task flow.

Using a web-based authentication allows disparate directory systems: there is no
requirement that the Partner devices are attached to the directory of the Customer.

Absent a system like this, many Customer would create a shared account in a VPN (
e.g. mspco@egov.city). This is highly risky, the password is known by multiple individuals
and difficult to rotate, and, impossible to provide multi-factor for (since you 
would need to share a device amongst the users). The Agilicus AnyX obviates this
need.

Each company (Partner, Customer) can individual control their users, manage their
own HR workflow in a natural fashion, without concerning themselves of their business
partners.

There is no need for the Partner companies to install a VPN per Customer, since 
the entire system is web-based.

### To Agilicus AnyX Customer

 * Increased compliance. Multifactor for all partners
 * Individual audit, per user, no shared accounts. Each action is attributable to
   a single individual, and individually controllable

### To Agilicus AnyX Customer Partner

 * simplified HR workflow, no need to notify customers
 * simplified IT on desktop, no VPN per customer
 * Reduced financial risk (no breach attributable to your user not obeying best 
   practices with multi-factor or shared accounts)
 * Reduced risk of spear-phishing since all users see same login flow for all systems,
   internal or external

### To End User

 * reduced sign-in fatigue
 * reduced password memorisation load
 * no concern about unlike sytems with unlike password rules