20170215: Azure AD application identities

Last updated: January 30, 2023
Audience: IT Staff / Technical

Status as of 1/9/2017

This proposal was approved by the Azure AD 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

Azure AD 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 AAD 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. AAD application identities are a requirement to use many Azure services, and the Microsoft recommended configuration allows any user to self-service add an AAD 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).

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

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

Azure AD application permissions come in two different types: user and admin. AAD 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. AAD 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. AAD application admin permissions also can not be incrementally added after AAD application creation without a tenant admin. In contrast, AAD application user permissions can be added after a given AAD application has been created, but the user must consent to any newly added permissions before the AAD application can leverage them. Currently this requires that the corresponding AAD servicePrincipal for the AAD 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 Azure AD application is the Azure AD Graph API. This Azure AD application identity is used by a RESTful web service interface by which you can query information about your Azure AD tenant. The AAD Graph API Azure AD 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 Azure AD application identity may provide–and that another AAD application identity may want to get access to.

Admin permissions for Azure AD 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 Azure AD 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 AAD Application resources (that are affordable) are inadequate to detect inappropriate scenarios
  • Existing Microsoft controls for granting AAD Application permissions are inadequate to provide appropriate risk management

Challenges

Azure AD 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 AAD application identities exist is one where we have little past experience. For example OAuth2 and OpenID Connect are two key core protocols for AAD 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 AAD 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.

Azure AD application identities are at the heart of Azure AD, the cloud based identity platform Microsoft is betting on. A poor strategy in our approach to Azure AD 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 Azure AD 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 Azure AD 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 AAD 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 AAD application identity.
  • High customer fulfillment latency. On average, it takes an estimated 6 weeks to add an AAD 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 AAD,  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 AAD apps that their department does not want them to use.

Benefits:

  • We have relative clarity about all AAD apps in our tenant
  • We have documentation about regulatory compliance and risk acceptance for AAD 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 AAD tenant settings for AAD 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 AAD application identities which require permissions at the user consent level. Tenant users can *not* add AAD application identities which require the tenant admin consent level.b) means that when a user tries to use an AAD application that someone else has added, they may be asked whether they consent to allow this AAD application to access their data in specific other AAD 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 AAD application identities for enabling new innovative business. NOTE: If those AAD application identities need tenant admin consent level permissions, they won’t be able to add those permissions themselves.

  2. An AAD application is deployed which enables monitoring of all AAD applications in our tenant for AAD 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 AAD 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 AAD application permissions. Requests are approved or denied by the MI Service Manager, with appeals to the AAD CAB.
  4. Add an AAD routine change: risky AAD application permissions can be approved by the Microsoft Infrastructure service manager.
  5. Build the tools required to fulfill requests to find out the AAD 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 AAD.
  6. There is a practice of regularly reviewing the output of this AAD application monitor and implementing mitigations as needed. Initially mitigations are limited to inappropriately added AAD 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 AAD CAB. Other scenarios and mitigations can be added, subject to approval by the AAD CAB. “Inappropriately added AAD applications” are any AAD application with risky permissions not approved by the Microsoft Infrastructure service manager or AAD CAB.
  7. Add an AAD routine change: disable inappropriately added AAD applications within 72 hours of addition.
  8. Amend the existing AAD Application request fulfillment process to only cover AAD applications with risky permissions, i.e. this process becomes renamed to “Risky AAD Application Request Fulfillment Process.”
    1. The concept of basic vs extended AAD applications is removed from that process
    2. Mention of Terms of Service is removed.
    3. The AAD 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 AAD app risk team is given more latitude to use whatever process they find useful to evaluate the risk of a given AAD application’s permissions.
    5. If the service manager or owner, system manager or owner, or data custodian representing an AAD application accepts the risk, then separate risk assessment or explicit AAD CAB decision is needed. The Microsoft Infrastructure service team must verify that the appropriate individual for that AAD application is accepting the risk. This scenario is considered a routine AAD 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 AAD 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 AAD 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 AAD 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 Azure AD, including addition of AAD 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 Azure AD 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 AAD changes documented.