Attribute | Model 1a – No Federation – AAD w/ hashes and Duo 2FA | Model 1b – No Federation – AAD w/ hashes and Azure 2FA | Model 3c – Federate with IdP | Model 5e – ADFS (current model) |
---|
Architectural simplicity | - Fewest authentication components; no proxies
- Fewest points of failure
- Most new provisioning components; sync password hashes
- Fewer new 2FA components; Duo 2FA integration
- ADFS and IdP still present for other applications
| - Fewest authentication components; no proxies
- Fewest points of failure
- Most new provisioning components; sync password hashes
- Most new 2FA components; Microsoft Authenticator, enrollment components, transaction logs
- ADFS and IdP still present for other applications
| - More authentication components; one proxy between AAD applications and authentication systems
- More points of failure
- No new provisioning components
- No new 2FA components
- ADFS and IdP still present for other applications
| - Most authentication components; two proxies between AAD applications and authentication systems
- Most points of failure
- No new provisioning components
- No new 2FA components
|
Protocols for primary (password) authentication | "Modern" and Web clients "Legacy" clients - Integrated Windows Authentication
| "Modern" and Web clients "Legacy" clients - Integrated Windows Authentication
| "Modern" and Web clients - OIDC and OAuth
- SAML2 browser profile
"Legacy" clients | "Modern" and Web clients - OIDC and OAuth
- WS-Trust and WS-Federation
- SAML2 browser profile
"Legacy" clients |
2FA triggering | "Modern" and Web clients - AAD conditional access rule triggers Duo 2FA at AAD
"Legacy" clients | "Modern" and Web clients - AAD conditional access rule triggers Azure 2FA at AAD
"Legacy" clients | "Modern" and Web clients - AAD conditional access rule triggers AAD to set authnContextClass when requesting 2FA from IdP
- IdP enforces 2FA based on requested authnContextClass (translation required) and authentication policy control
"Legacy" clients - Maybe? Append 2FA passcode to password and IdP extracts two elements to verify? IdP would have to submit username/code to 2FA API rather than use Duo iframe.
| "Modern" and Web clients - AAD conditional access rule triggers AAD to send 2FA signal to ADFS
- ADFS custom claims rule triggers ADFS to use authnContextClass when requesting 2FA from IdP
- IdP enforces 2FA based on requested authnContextClass (translation required) and authentication policy control
"Legacy" clients |
Authentication policy control | - AAD conditional access rules can apply policy based on application, application type, user, group, device, device type, network, and real-time risk score
- AAD conditional access can detect modern and legacy clients and can enforce 2FA for modern clients only
- Duo provides additional policy controls for 2FA
| - AAD conditional access rules can apply policy based on application, application type, user, group, device, device type, network, and real-time risk score
- AAD conditional access can detect modern and legacy clients and can enforce 2FA for modern clients only
| - IdP can directly apply policy based on user or group
- IdP can't directly apply policy based on application; AAD is the only "application" visible to IdP
- IdP can't currently apply policy based on device, device type, network, or real-time risk score
- The IdP can enforce 2FA policy based on authnContextClass class sent from AAD
- Duo provides additional policy controls for 2FA
| - IdP can directly apply policy based on user or group
- IdP can't directly apply policy based on application; ADFS is the only "application" visible to IdP
- IdP can't currently apply policy based on target device, device type, network, or real-time risk score
- The IdP can enforce 2FA policy based on authnContextClass class sent from ADFS
- Duo provides additional policy controls for 2FA
|
User Experience | Primary authentication - Users must use two main web authentication interfaces among UW-IT supported applications (AAD and IdP)
Second factor - "Modern" and Web clients continue to use Duo for 2FA
- No 2FA support for "Legacy" clients
| Primary authentication - Users must use two main web authentication interfaces among UW-IT supported applications (AAD and IdP)
Second factor - "Modern" and Web clients use Azure 2FA
- To use push notification with Azure 2FA, users must install Microsoft Authenticator and enroll their 2FA device
- It should be possible to use the Duo mobile app or Microsoft Authenticator for TOTP passcodes with Azure 2FA
- Users must manage their 2FA devices in two different systems (AAD and Duo)
- No 2FA support for "Legacy" clients
| Primary authentication - IdP retains role as primary web authentication interface among UW-IT supported applications
Second factor - "Modern" and Web clients continue to use Duo for 2FA
- SAML ECP experience for "Legacy" clients, if this is possible, would require users to append a Duo device code or a 2FA passcode to their password.
| Primary authentication - IdP retains role as primary web authentication interface among UW-IT supported applications
Second factor - "Modern" and Web clients continue to use Duo for 2FA
- No 2FA support for "Legacy" clients
|
Password Security | - Requires syncing password hashes to AAD, which is new
- There are good controls to manage the security risk
- Syncing hashes enables benefits from AAD Identity Protection (e.g. detect compromised accounts)
- Requires users to recognize new secure location to enter passwords
| - Requires syncing password hashes to AAD, which is new
- There are good controls to manage the security risk
- Syncing hashes enables benefits from AAD Identity Protection (e.g. detect compromised accounts)
- Requires users to recognize new secure location to enter passwords
| - Syncing password hashes not required
- If the benefits of AAD Identity Protection are desired, that can also be done independently from this option
- Use of ECP for legacy clients, if possible, exposes user passwords to proxy
| - Syncing password hashes not required
- If the benefits of AAD Identity Protection are desired, that can also be done independently from this option
|
Available 2FA factors | - Supports all Duo 2FA options
- Push notifications
- TOTP passcodes
- HOTP hardware tokens
- U2F tokens
- Phone call back
- Bypass codes
- SMS (disabled in UW Duo tenant)
| - Supports all Azure 2FA options
- Push notifications
- TOTP passcodes
- HOTP hardware tokens (coming)
- Phone call back
- SMS
| - Supports all Duo 2FA options
- Push notifications
- TOTP passcodes
- HOTP hardware tokens
- U2F tokens
- Phone call back
- Bypass codes
- SMS (disabled in UW Duo tenant)
| - Supports all Duo 2FA options
- Push notifications
- TOTP passcodes
- HOTP hardware tokens
- U2F tokens
- Phone call back
- Bypass codes
- SMS (disabled in UW Duo tenant)
|
Windows Hello for Business | | - Compatible
- Provides stronger forms of authentication for workstation sign in
| | |
Non-authentication impacts to AAD environment | - Supports AAD device join
- AAD device join may be key to future device management strategy
| - Supports AAD device join
- AAD device join may be key to future device management strategy
| - SAML federation prevents AAD device join (dependence on WS-Trust)
- Azure SQL (and an undocumented list of some other Azure services) require WS-Trust and could not function with this option
| - Supports AAD device join
- AAD device join may be key to future device management strategy
|
Product support | - Technology stack provided by Microsoft AAD and Duo
- Two support providers
- Potentially longer times to diagnosis and repair with two parties
| - Full technology stack is provided by Microsoft AAD
- Only one support provider
- In theory, the simplest to support, with shorter time to diagnosis and repair
| - Technology stack provided by Microsoft AAD, Duo, and UW IdP
- Three support providers
- Potentially longer times to diagnosis and repair with three parties
| - Technology stack provided by Microsoft AAD, Microsoft ADFS, Duo, and UW IdP
- Three support providers
- Potentially longer times to diagnosis and repair with three parties
|
Transition impacts on AAD | - Changing the AAD federation model takes 1-4 hrs
- Potential for client impact, expected to be minimal
| - Changing the AAD federation model takes 1-4 hrs
- Potential for client impact, expected to be minimal
| - Changing the AAD federation model takes 1-4 hrs
- Potential for client impact, expected to be minimal
| - This is the current AAD federation model, no change is required
|
Licenses/Cost | - Using the Duo integration in AAD requires a Microsoft AAD P1 license. This is covered by a M365 A3 license, which students and employees have, but other populations would need to purchase
- Requires no additional Duo licenses for existing user base
- Adding new populations that require a Duo "hospital" license would incur a large increase in annual Duo license costs
- Using Duo for O365/AAD would increase Duo utilization 23-fold1, which would drive up telephony charges to about $434K/year
- Telephony costs could be reduced by using "remember me" functionality
| - Requires no additional licenses or costs for existing user base
| - Requires no additional Duo licenses for existing user base
- Adding new populations that require a Duo "hospital" license would incur a large increase in annual Duo license costs
- Using Duo for O365/AAD would increase Duo utilization 23-fold1, which would drive up telephony charges to about $434K/year
- Telephony costs could be reduced by using "remember me" functionality
| - Requires no additional Duo licenses for existing user base
- Adding new populations that require a Duo "hospital" license would incur a large increase in annual Duo license costs
- Using Duo for O365/AAD would increase Duo utilization 23-fold1, which would drive up telephony charges to about $434K/year
- Telephony costs could be reduced by using "remember me" functionality
|