Child pages
  • Copy of Azure AD Application Request Fulfillment Process
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Status: Production

Purpose

A request fulfillment process for handling UWWI 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.

UWWI Support

Coordinator

Support the requestor through this process.

UWWI 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.
UWWI 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 UWWI Support role is filled by the service team members.

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

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 UWWI 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 UWWI 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 UWWI 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. UWWI 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 UWWI Service Manager. Extended approval is fulfilled by the AAD App Approval team.
  3. If required, UWWI Support coordinates approval from UWWI Service Manager. 
    1. UWWI Support creates a RTASK assigned to UWWI Service Manager.
    2. UWWI Service Manager documents simple application scores based on supplied information.
    3. UWWI Service Manager indicates approval decision to UWWI Support. 
  4. If required, UWWI Support coordinates approval from the AAD App Risk Scoring Team. Assign request to UWWI Service Manager.
    1. UWWI 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 UWWI Service Manager and marks the RTASK complete.
  5. UWWI Service Manager reviews risk scores and any suggested mitigations then makes a decision on whether to proceed with approval
    1. UWWI Service Manager discusses potential mitigations with requestor to identify if they are acceptable.
    2. If an application has acceptable risk it is approved
  6. UWWI 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 UWWI Engineering.
    1. Ask UWWI Engineering to add requested AAD application.
    2. UWWI Engineering adds requested AAD application.
    3. UWWI Support updates UWWI 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. UWWI Support responds to Customer: You're good to go.
  9. UWWI 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:
  • how external users fit in,
  • whether there's a way to turn on user consent without losing organizational control,
  • how apps can use our AAD identities w/o being an app in our tenant (we know that some mobile apps don't need an AAD app, but why isn't understood) 

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.

 

  • No labels