IAM in Service Catalog
In order to provide functionality for UW Medicine, MSCA needs an Exchange Enabled security group.
This group is critical to implement:
It can potentially be used for scoping in Cloud App Security.
The membership should include:
The Exchange settings should be:
TBD – No one, Anyone, Members of a specified group, list of groups or netids
The solution architecture includes the following constraints:
Note: we have asked Microsoft to increase their limit, and where is this ask is being tracked; let's shift this to the related AAD govteam discussion.
MSCA may have forgotten about some of the groups is this area, which they referenced in REQ1385495 to obtain access to the groups service.
These same groups are also described on this page:
If you click through to the groups themselves, none are larger than 50K.
To move forward:
1. We need someone to help you confirm a mapping between the subscription codes you listed in this request and these existing groups:
13: UW Medicine Workforce = uw_affiliation_uw-medicine-workforce
76: UWP Provider = uw_affiliation_uwp-provider
77: UWP Admin Staff = uw_affiliation_uwp-staff
80: UWPN Admin Staff = uw_affiliation_uwnc-staff (TBD? maybe?)
104: NWHMC Admin Staff = uw_affiliation_nwh-staff
105: NWHMC Provider = uw_affiliation_nwh-provider
Note: There is an "Audience RX" product that UWM Marketing was using that introduces a different business and technical definition of UWM workforce that includes UWP, UWPN, NWH, Valley, Workday (by box number), but not "Workforce" people as provided to IAM from UWM's Puma database integration.
2. There is no reference group for "22: UW Medicine Shared", so we can draft a design proposal here:
Clinical shared UW NetID group design
Note: Above MSCA team refers to "Clinical Shared NetIDs available in Azure AD" which may or may not be the same as "22: UW Medicine Shared".
Given the requirements and constraints, what proposed designs do we have for provisioning to AAD?
It might be simplest to model the overall membership as a policy group in the groups service (e.g. u_msca_uwm-exchange-access), and have it include whatever reference groups it should include over time, and then either:
(a) if less than 50K members, exchange enable the groups and sync them over to AAD through the current design through AD, or
(b) sync the one group and its effective membership directly to AAD via the graph API or other direct methods.
Based on the proposed design decisions above...
3. We need to get authorization to integrate the group membership data into the new target systems (AD, AAD, Exchange) and therefore disclose data to new data viewers. This is the item that I'm responsible for coordinating, and I'll request a discussion about this at the next Azure AD govteam meeting. In particular, we need to document the AD, AAD, Exchange access policies with respect to data disclosure. We have a good set of subject matter experts who understand the technical controls applied to data in these systems, and we can translate that into an access policy in natural language that data custodians can understand.