Child pages
  • Copy of Azure AD Application Request Fulfillment Process

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Status: Production

NOTE: This is a copy of the original document. This copy is intended for those outside the UW Windows Microsoft Infrastructure service team to reference.


Status: Production (prior version of this document)

Existing version of this document will become production on 1/11/2017


A request fulfillment process for handling MI requests for Azure AD application requestsapplications with risky permissions.


  1. Enable business use
  2. Show due care for integration with UW resources
    1. Document regulatory compliance
    2. Document apps which may have data subject to regulatory concerns
  3. Protect confidential data leaks (hippa, ferpa, etc)
  4. Mitigate risks
  5. Enable business use 
  6. confidential data


The following parties are involved in this process. Listed by name, role, and responsibilities.






Submit the request for Azure AD application with sufficient information needed by approvers.

MI Support


Support the requestor through this process.

MI Engineering


Configure/create application if the request is approved.

AAD App Risk Scoring Team


For extended approvals, assess application as fit for use, identifying potential/necessary mitigations so applications are fit for use

AAD App Risk Review TeamReviewer/Consultant On a periodic basis, review application applications for risk scores. On an as needed basis, provide consulting on application risk scoring risks and suggested mitigations.
MI Service Manager Approver For basic approvals, approve application as fit for use. For extended approvals, taking risk assessment and ensuring any necessary mitigation is applied to applications before approving application for use.


The AAD App Risk Scoring team is:

  • Greg Frick
  • Eric Kool-Brown
  • Shawn Drew
  • Jonathan Pass
  • Roland Lai
  • Chad Haffenden
  • John Soltys

The AAD App Risk Review Team is filled by a representative from the Attorney General's Office, Office of the CISO, and Risk Management.

The MI Service manager is filled by the service manager or their designated alternate during leave.

Basic Request vs. Extended Request


Basic requests include the following:

  • Any request that involves only creating an Azure AD servicePrincipal, i.e. the application just needs to be able to authenticate itself. For example, Azure Key Vault.
  • Any request for an application which only requires permissions to Azure AD. The MI service team can fulfill these types of requests in consultation with the Directory Services and Authentication service teams and appropriate data custodians.

 Extended requests include the following:

  • Any request for an application that requires permissions to Exchange Online, Sharepoint Online, OneDrive for Business, Skype for Business or Lync Online, Yammer Enterprise, Sway, or other applications in the Office 365 suite.
  • Any request for an application that requires permissions to AAD application in our tenant.
  • Any request for an application that requires a user to agree to Terms of Service

Entry criteria

  1. Applicant submits MI Azure AD Application Request Form resulting in a new UW Connect record. Or they initiate some future AAD app request workflow, hopefully also resulting in a new UW Connect record.
  2. The UW Connect record is assigned to CI=UW Windows InfrastructureAzure AD, Assignment Group=UW Windows Microsoft Infrastructure.

Process steps

  1. MI Support reviews the customer's request for required information:
    1. Verify the Type of AAD application is provided.
    2. Verify the Access to other AAD applications being requested is described sufficiently that we know what the client is requesting.
    3. Verify that if there are Terms of Service, a URL to them is provided.Verify the Business Need is described.
    4. Verify the Data Use & Exposure is described.
    5. Coordinate with Customer to ensure all required information is available for approvers.
    6. If necessary, add application in dogfood tenant to determine any unclear information and/or clarify with the customer anything missing or unclear.
    7. When required information is provided, coordinate expectations with Customer: you're now moving on to the approval stage.
  2. Based on Type of AAD application and Access to other AAD applications being requested determine which kind of approval is needed: Basic or Extended. Basic approval is fulfilled by MI Service Manager. Extended approval is fulfilled by the AAD App Approval team.
  3. If required, MI Support coordinates approval from MI Service Manager. 
    1. MI Support creates a RTASK assigned to MI Service Manager.
    2. MI Service Manager documents simple application scores based on supplied information.
    3. MI Service Manager indicates approval decision to MI Support. 
  4. If required, MI Support coordinates approval from MI Support passes the baton to a member of the AAD App Risk Scoring Team. Assign request to MI Service Manager.:
    1. MI Support creates a RTASK assigned to a member of the AAD App Risk Scoring Team. <details of what is in that RTASK to be decided and added here>Description should clearly say "we have a risky AAD app which needs analysis for approval".
    2. RTask owner on AAD App Risk Scoring Team creates an entry for the app at owner on notifies AAD App Risk Scoring Team asks team about need to review app and submit scores.RTask owner on
    3. AAD App Risk Scoring Team tallies scores and computes average score.
    4. RTask owner on AAD App Risk Scoring Team determines if team needs to discuss mitigations. If discussion is needed, coordinate and facilitate  mitigation discussion.
    5. RTask owner on AAD App Risk Scoring Team documents average score and reviews details provided, does whatever activities are needed, and renders a decision. That decision may include conditional approval pending mitigations. NOTE: If there is a clear service manager/owner, system manager/owner, or data custodian representing the AAD application permission that the requested risky AAD app needs, then that individual can/should be approached to make a risk acceptance decision. In that case, no decision is needed from App Risk Scoring team, and in step #4 we open a routine change which does not need CAB approval. For example, if application Q wanted Directory.Read.All, the MI service manager could make a decision. If application J wanted OneDrive.SpecialAdminPermission (there is no such thing), the MSCA service manager could make a decision.
    6. RTask owner documents decision and the rationale behind that decision and any suggested mitigations for historical review.
    7. Via the RTASK, the RTask owner on AAD App Risk Scoring Team indicates score and suggested mitigations to MI Service Manager and marks the RTASK complete.
    MI Service Manager reviews risk scores and any suggested mitigations then makes a
    1. RTask owner communicates decision. If discussion is needed, coordinate and facilitate mitigation discussion.
    2. RTASK is marked complete.
  5. MI Support reviews decision on whether to proceed with approval
    1. MI Service Manager discusses potential mitigations with requestor to identify if they are acceptable.
    2. If an application has acceptable risk it is approved
  6. MI Service Manager send app approval to AAD Change Advisory Board for additional decision. NOTE: if in 2c the risk was accepted by a specific owner/manager/steward, then a routine change is open, approved, and no decision by the CAB is needed. 
    1. AAD CAB supplies its own process for reviewing app approvals. Note

    2. If approved, move on to #7. 
    3. If denied, service manager reviews concerns and may start over at a prior step or communicate denial to customer.
  7. Request owner coordinates access with MI Engineering.
    1. Ask MI Engineering to add requested AAD application.
    2. MI Engineering adds requested AAD application.
    3. MI Support updates MI AAD Apps - Fulfilled Requests <need link here>Requests Azure AD Application - Fulfilled Requests
      1. Record the Application that was authorized and the requestor.
      2. Record the access granted.
      3. Record the UW Connect record number tied to the request and approvals.
      4. Record the status of the request.
      5. Record the data exposure.
      6. Record any required mitigations
      7. Record the approval date.
      8. Record notes as needed.
      9. Save. (smile)
  8. MI Support responds to Customer: You're good to go.
  9. MI Support resolves UW Connect record.

Known Issues

  1. We don't fully understand the Azure AD application architecture. We'll continue efforts to understand how this works. Need to understand:



As answers are available, they'll be shared and this process will be revisited by the Azure AD governance team to review past decisions and adjust the guidance.

2. AAD Apps which require user consent are not allowed at this time. They may be allowed in the future, pending progress on #1 or confidence that the AAD app risk review team can handle this additional complicating factor. For user consent, consider whether EULA needs to be addressed.