20170215: Entra ID application identities

Last updated: November 15, 2023
Audience: IT Staff / Technical

Status as of 1/9/2017

This proposal was approved by the Entra ID CAB in October 2016. This proposal (Option #2) was approved by the Enterprise CAB in December 2016. Implementation on February 15, 2017.  For details about how the change is being communicated and implemented,  please follow UW Connect Change Record CHG0031629

Background

Entra ID application identities are currently available with customer details at /tools-services-support/it-systems-infrastructure/msinf/aad/apps/, including a request form, and information about what they are.

Current availability of Entra ID application identities would be described by most everyone as poor at best, with an expected wait time of weeks to months to get one, and a lot of labor involved to fulfill a request. Entra ID application identities are a requirement to use many Azure services, and the Microsoft recommended configuration allows any user to self-service add an Entra ID application identity. So our current status remains an outlier in terms of enabling business needs.

We have arrived at our current status because of concerns about managing risk. Some of those concerns were well-founded and others were based on inadequate information. Microsoft was not timely in helping to addressing gaps in understanding, despite close ties to the product team so these concerns have had a while to grow in imagined significance. Most of those gaps have been filled now, with only a few past observed oddities outstanding that may never be answered (and may never recur).

Entra ID application identities operate within the context of an Entra ID Change process: https://wiki.cac.washington.edu/x/2ktJB.

Entra ID application identities are fulfilled via an Entra ID app request process: https://wiki.cac.washington.edu/x/p-1NB.

Entra ID application permissions come in two different types: user and admin. Entra ID application user permissions are granted by a user for the corresponding resources in that application indicated by the permission, and are limited to what that user has access to. The granting of these permissions happens via a user consent experience, usually done at the time the user tries to use the application for the first time–but they can happen incrementally when a user wants to use a feature that requires that permission. Entra ID application admin permissions can only be granted by a tenant admin, and when they are present, the application can not be created with that permission without a tenant admin. Entra ID application admin permissions also can not be incrementally added after Entra ID application creation without a tenant admin. In contrast, Entra ID application user permissions can be added after a given Entra ID application has been created, but the user must consent to any newly added permissions before the Entra ID application can leverage them. Currently this requires that the corresponding Entra ID servicePrincipal for the Entra ID application be deleted and recreated (which means that every user must re-consent), but Microsoft plans to fix this issue so that there is just an incremental consent experience for users which have previously consented to an earlier set of permissions.

An example of an Entra ID application is the Microsoft Graph API. This Entra ID application identity is used by a RESTful web service interface by which you can query information about your Entra ID tenant. The Entra ID Graph API Entra ID application identity has 3 user permissions and 6 admin permissions. These are listed below to provide a concrete example of the kinds of permissions that an Entra ID application identity may provide–and that another Entra ID application identity may want to get access to.

Admin permissions for Microsoft Graph API

    • Read hidden memberships [Member.Read.Hidden]
    • Read all users’ full profiles [User.Read.All]
    • Read all groups [Group.Read.All]
    • Write all groups [Group.Write.All]
    • Read and write all directory data [Directory.ReadWrite.All]
    • Read all directory data [Directory.Read.All]

User permissions for Microsoft Graph API

    • Sign in and read user profile [User.Read]
    • Read all users’ basic profiles [User.ReadBasic.All]
    • Access the directory as the signed-in user [Directory.AccessAsUser.All]

Goal Statement

  1. Enable business use with a minimum of friction
  2. Mitigate risks with due care for integration with UW confidential data

Assumptions

Should these assumptions change, a re-analysis and possible change in approach would be appropriate:

  • Existing Microsoft Entra ID Application resources (that are affordable) are inadequate to detect inappropriate scenarios
  • Existing Microsoft controls for granting Entra ID Application permissions are inadequate to provide appropriate risk management

Challenges

Entra ID application identities are complex.

Many get stuck on the “application” part of the name, focusing on the software/code aspect, but the reality is that these are identities, whose risk is in what permissions they have–just like any other identity. This issue can and has affected our past thinking about how to approach these, to the point that these identities are the most difficult to get of any identity managed by UW-IT.

The technical background within which Entra ID application identities exist is one where we have little past experience. For example OAuth2 and OpenID Connect are two key core protocols for Entra ID application identities which we have little previous experience with. And because there are aspects to these protocols which are left to implementers, prior experience may not be entirely relevant.

Microsoft has been slow to document the design of Entra ID application identities. A recently published book by a Microsoft PM (Modern Authentication with Azure Active Directory for Web Applications) goes a significant way toward filling the gaps, but some aspects are murky, and based on our inquiries Microsoft seems reluctant to share details on topics that seem to be outside what is well-known.

By nature, applications consume data. Data custodians have an interest in the risks involved. Ensuring the needs and concerns of those stakeholders are represented is a challenge.

Entra ID application identities are at the heart of Entra ID , the cloud based identity platform Microsoft is betting on. A poor strategy in our approach to Entra ID application identities has ripple effects on our ability to leverage Microsoft services. A good example of this is an existing request where the folks running our Managed Server service must wait many weeks to get an Entra ID application identity that has permissions to the resources they manage and already have direct administrative access to via their personal identities. Put simply, a poor approach to Entra ID application identities can have a real impact on meeting business needs.

Design Options

Over the last year, there have been two schools of thought about possible design options. One option is what we are currently using, and the other has been discussed as a possible future.

Option 1:

Description:

“Gatekeeper approach”

Existing approach as documented by the combination of /tools-services-support/it-systems-infrastructure/msinf/aad/apps/,  https://wiki.cac.washington.edu/x/2ktJB, and https://wiki.cac.washington.edu/x/p-1NB. With this approach, every Entra ID app must be examined by the Microsoft Infrastructure service team (and may need to first be installed in an evaluation tenant), may need to have risk analysis performed by multiple individuals, then may need to be approved in a once a month activity.

Downsides:

  • Labor intensive. On average, it takes an estimated 6 hours of effort to add an Entra ID application identity.
  • High customer fulfillment latency. On average, it takes an estimated 6 weeks to add an Entra ID application identity.
  • Customers working with a vendor may need duplicative licensing to accommodate our evaluation
  • High amount of friction/bandwidth means many useful apps are not available to customers.   For many customers, this means they will install apps locally via other means.  By blocking installation of per-user apps via Entra ID, we are likely causing higher risk to the institution due to a lack of visibility of what apps are installed & used by individuals.
  • Users may be able to install & use Entra ID apps that their department does not want them to use.

Benefits:

  • We have relative clarity about all Entra ID apps in our tenant
  • We have documentation about regulatory compliance and risk acceptance for Entra ID use (but not for BYOD systems).

Outlook: Very poor. This will not scale, and customers are likely to try to go around us–either using this technology or others. The benefits are completely offset by this likelihood. We have sacrificed goal #1 to rigorously meet goal #2.

—

Option 2:

Description:

Move to the default approach Microsoft recommends, augmented by some practices to help detect and mitigate risks. This approach is sometimes referred to as the “monitor and mitigate” approach.

Changes required to implement this approach:

  1. In this approach, we change the Entra ID tenant settings for Entra ID applications back to their default values, i.e.:
    a. User can add gallery apps to their Access Panel: No -> Yes
    b. Users can allow apps to access their data: No -> Yes
    c. Users can register applications: No -> Yesa) means tenant users can add Entra ID application identities which require permissions at the user consent level. Tenant users can *not* add Entra ID application identities which require the tenant admin consent level.b) means that when a user tries to use an Entra ID application that someone else has added, they may be asked whether they consent to allow this Entra ID application to access their data in specific other Entra ID applications. In other words, the user is put in the driver’s seat of risk evaluation for data specific to them.c) means that UW developers and cloud integrators can create Entra ID application identities for enabling new innovative business. NOTE: If those Entra ID application identities need tenant admin consent level permissions, they won’t be able to add those permissions themselves.
  2. An Entra ID application is deployed which enables monitoring of all Entra ID applications in our tenant for Entra ID apps with notably risky permissions. Initially, risky permissions are defined to be permissions requiring tenant admin consent, but this definition can change over time to meet significant business concerns. For example, if in the future, we needed to flag any scenario where a specific individual granted consent to their data in a given Entra ID app, that could be added.
    NOTE: We know of only two scenarios where tenant admin consent level permissions can be added: one of our tenant admins adds it or Microsoft adds it via one of several actors internal to Microsoft. So initially, this is protection for actions taken by our tenant admins and Microsoft.
  3. There is a new Microsoft Infrastructure request process for suggesting new risky Entra ID application permissions. Requests are approved or denied by the MI Service Manager, with appeals to the Entra ID CAB.
  4. Add an Entra ID routine change: risky Entra ID application permissions can be approved by the Microsoft Infrastructure service manager.
  5. Build the tools required to fulfill requests to find out the Entra ID consent permissions granted by an individual. This can help to meet the needs of auditors and IT staff tasked with meeting regulatory requirements. This goes along with another more general known need to have audit log data and analysis tools for Entra ID.
  6. There is a practice of regularly reviewing the output of this Entra ID application monitor and implementing mitigations as needed. Initially mitigations are limited to inappropriately added Entra ID applications that have been in place less than 72 hours and disabling them until appropriate further review can happen, with an ultimate decision resting with the Entra ID CAB. Other scenarios and mitigations can be added, subject to approval by the Entra ID CAB. “Inappropriately added Entra ID applications” are any Entra ID application with risky permissions not approved by the Microsoft Infrastructure service manager or Entra ID CAB.
  7. Add an Entra ID routine change: disable inappropriately added Entra ID applications within 72 hours of addition.
  8. Amend the existing Entra ID Application request fulfillment process to only cover Entra ID applications with risky permissions, i.e. this process becomes renamed to “Risky Entra ID Application Request Fulfillment Process.”
    1. The concept of basic vs extended Entra ID applications is removed from that process
    2. Mention of Terms of Service is removed.
    3. The Entra ID app risk scoring team is amended to be Eric Kool-Brown, Jonathan Pass, Roland Lai, and Shawn Drew. This provides customer input and individuals who perform a similar function for integration via our Shibboleth services, and matches what our current practice is.
    4. The Entra ID app risk team is given more latitude to use whatever process they find useful to evaluate the risk of a given Entra ID application’s permissions.
    5. If the service manager or owner, system manager or owner, or data custodian representing an Entra ID application accepts the risk, then separate risk assessment or explicit Entra ID CAB decision is needed. The Microsoft Infrastructure service team must verify that the appropriate individual for that Entra ID application is accepting the risk. This scenario is considered a routine Entra ID change.
    6. MI service manager is not required in the process–any MI service team member can do the tasks previously noted as only the MI service manager.
    7. Known Issues is updated
    8. Goals are amended to match the goals noted here
    9. Purpose is amended to reflect this change

Downsides:

  • There will be an ever increasing number of Entra ID Application identities in our tenant. A lifecycle policy may eventually be needed to manage this.
  • Users are trusted to make good decisions about their data in other Entra ID applications. Lack of training or awareness may lead to poor decisions and outcomes which put confidential data at risk. NOTE: This downside is present in pretty much every existing application ecosystem at the UW.

Benefits:

  • Business uses are enabled with a minimum of friction
  • This approach scales to meet customer demand
  • This approach can mitigate risks as they are identified

Outlook: Acceptable. This requires some additional one-time investment but can scale and adapt to meet changing business needs. This meets goal #1 and #2.

Open Issues

Need to finish building Entra ID app monitor noted in #2 above. As of 1/9/2017,  this tool is ~80% complete and is being used to monitor any significant change to Entra ID, including addition of Entra ID applications. Completion will result in automated incident creation when “risky” applications are discovered, and broaden the availability of data being collected by the application to the entire service team. Note: we are not solely dependent on this tool; we can manually validate status. ETA for completion is: 2/15/2017

Need to build tool noted in change #5. The audit function this tool provides can be done manually today by any UW identity, so this tool is a courtesy tool to help those unknowledgeable with getting this information. So this tool is not considered a blocker toward immediate implementation.  ETA for completion is: 2/15/2017.

Customer guidance and documentation about user consent decisions posed by Entra ID application identities is needed. Microsoft Infrastructure can & will publish documentation, but the effectiveness of documentation alone is likely not sufficient to not call this an open issue–a training campaign like that posed in a business case a couple years ago would be better.

Recommendation

Implement approach #2 as noted in the Design Options, with approval for the 8 Entra ID changes documented.