Status: Production

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

Purpose

A request fulfillment process for handling MI Azure AD application requests.

Goals

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

Roles

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

Name

Role

Responsibility

Customer

Requestor

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

MI Support

Coordinator

Support the requestor through this process.

MI Engineering

Authorizer

Configure/create application if the request is approved.

AAD App Risk Scoring Team

Assessor 

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 risk scores. On an as needed basis, provide consulting on application risk scoring 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 MI Support role is filled by the service team members.

The MI Engineering role is filled by the service team engineers.

The AAD App Risk Scoring team is:

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

BasicExtended

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 Infrastructure, Assignment Group=UW Windows 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.
    4. Verify the Business Need is described.
    5. Verify the Data Use & Exposure is described.
    6. Coordinate with Customer to ensure all required information is available for approvers.
    7. If necessary, add application in dogfood tenant to determine any unclear information and/or clarify with the customer anything missing or unclear.
    8. 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 the AAD App Risk Scoring Team. Assign request to MI Service Manager.
    1. MI Support creates a RTASK assigned to AAD App Risk Scoring Team. <details of what is in that RTASK to be decided and added here>
    2. RTask owner on AAD App Risk Scoring Team creates an entry for the app at https://sharepoint.washington.edu/uwtech/CollabApps/ERMMSCloud/default.aspx.
    3. RTask owner on AAD App Risk Scoring Team asks team to review app and submit scores.
    4. RTask owner on AAD App Risk Scoring Team tallies scores and computes average score.
    5. RTask owner on AAD App Risk Scoring Team determines if team needs to discuss mitigations. If discussion is needed, coordinate and facilitate  mitigation discussion.
    6. RTask owner on AAD App Risk Scoring Team documents average score 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.
  5. MI Service Manager reviews risk scores and any suggested mitigations then makes a 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.
    1. AAD CAB supplies its own process for reviewing app approvals

    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>
      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.