EE: Certificate Based Authentication (CBA)
Target release | Unknown |
---|---|
Epic | MM-22121: Certificate Based Authentication - Officially Supported Closed |
Edition | E20 |
Document status | 50% |
Document owner | @Dennis Kittrell (Deactivated) |
---|---|
Designer | @Michael Gamble (Deactivated) |
Tech lead | @Scott Bishel |
Technical writers | @Justine Geffen (Deactivated) |
QA | @Rohitesh Gupta (Deactivated) |
Working Group Contributors | @Eric Sethna (Unlicensed) @Adam Clarkson (Deactivated) @Elias Nahum |
OKR | Continue to add high priority business value improvements for enterprise customers |
Request (CR) | |
Request (other) | |
Design Spec |
|
Technical Spec |
|
Test Plan |
|
UPDATE: as of v1.29 of the mobile app, CBA for iOS is broken
Per mobile team, we are unable to fix CBA on iOS until v2 of the mobile app (without negatively impacting performance and possibly security for all users)
Objective
To officially support user and device based authentication (both primary and secondary) through the use of digital certificates.
Background
Large government, financial institutions, and other security-minded enterprise customers require Certificate Based Authentication for an added measure of securing access to communications.
The current status of CBA support is as follows:
Server-side CBA support is in experimental stage as documented here
Currently supports password-less access with primary and secondary access with credentials required.
Primary
: After the client side certificate is verified, user’s email is retrieved from the certificate and is used to log in without a password.Secondary
: After the client side certificate is verified, user’s email is retrieved from the certificate and matched against the one supplied by the user. If they match, the user logs in with regular email/password credentials.
iOS CBA support functions but does not support EMM certificate management via the iOS keychain
Android CBA support (while we have had partners contribute to the effort) has not been started internally
Success metrics
Goal | Metric |
---|---|
CBA support is no longer a purchase decision blocker for enterprise customers | Less than 5% of closed-lost, at-risk, churn reasons are related to CBA |
Existing customers with CBA requirements for expansion are unblocked | 100% of customers listed in the CR confirm the feature solves their use-case. |
User Scenarios
Customer IT team can distribute user certificates to devices securely (using EMM/MDM tools)
App user with certificate installed can access MM without a password
App user is authenticated using a certificate as a secondary method of authentication (potentially can be done via IdP which is more secure)
User authentication can be used in combination with machine/device authentication (which potentially can be done at the network level)
(TBD) Machine/Device authentication with custom field mapping
(TBD) Machine/Device authentication performs regular certificate checks for higher security
Assumptions
Enterprise customers will provide their own certificates and distribution method to users and devices.
User authentication will be used for:
MM Application Access (WebApp, Desktop Apps, and Mobile Apps)
Accessing internal networks, or intranets that allow access to MM
Machine/Device authentication will be used for:
Identifying all devices before allowing access to WiFi networks, VPNs, Gateways, etc that may be required to access MM.
(TBD) Identifying in-field devices before allowing access to MM
(TBD) Identifying all MM servers within the enterprise to enable mutual authentication
Constraints
TBD
Dependencies
Active Directory/LDAP Server Signing Requirements
Certificate Repositories and Keystores
Phases & Milestones
VERY EARLY ESTIMATES - THIS IS NOT A RELEASE SCHEDULE
Areas Touched
Authentication
Mobile
Desktop
WebApp
Requirements
Requirement | User Story | Importance | Status | Jira Issue | Notes | |
---|---|---|---|---|---|---|
1 | System Admin can distribute user certificates to iOS devices securely (using EMM/MDM tools) |
| HIGH |
|
|
|
2 | System Admin can distribute user certificates to Android devices securely (using EMM/MDM tools) |
| HIGH |
|
|
|
3 | System Admin can distribute user certificates to MacOS devices securely |
|
|
|
|
|
4 | System Admin can distribute user certificates to Windows PC devices securely |
|
|
|
|
|
5 | iOS user is authenticated using a certificate as a secondary method of identity |
| MEDIUM | DONE |
|
|
6 | Android user is authenticated using a certificate as a secondary method of identity |
|
|
|
|
|
7 | MacOS user is authenticated using a certificate as a secondary method of identity |
|
|
|
|
|
8 | Windows PC user is authenticated using a certificate as a secondary method of identity |
|
|
|
|
|
9 | WebApp user is authenticated using a certificate as a secondary method of identity |
|
| DONE |
|
|
10 | iOS user with certificate installed can access MM without a password |
|
| DONE |
|
|
11 | Android user with certificate installed can access MM without a password |
|
|
|
|
|
12 | MacOS user with certificate installed can access MM without a password |
| MEDIUM |
|
|
|
13 | Windows PC user with certificate installed can access MM without a password |
| LOW |
|
|
|
14 | WebApp user with certificate installed can access MM without a password |
|
|
|
|
|
Open Questions
Question | Answer | Date Answered |
---|---|---|
Do enterprise customers want to map our fields to their own custom field structure for certificates? Or can we ensure the common name or “subject alternate name” is mapped for most - and for PIV, we use the standard identifiers. Or can we simply document the format and structure for these and provide to the customer? What kind of fields and how many do they use? |
|
|
Is there a use-case where the User Certificate is confirmed regularly? Or only upon login? | All current customers/prospects answered NO to this requirement. | Early Feb 2020 |
Using a reverse proxy - could E20 license be side-stepped in current implementation of experimental version? |
|
|
|
|
|
Out of Scope (TBD)
Custom mapped certificate fields - If this is only necessary for device/machine auth, we may remove it
Device/Machine based authentication - we need to determine if this is needed (customers can do this at the network access level)
Decision Log