Manage user certificate authenticators
A user certificate authenticator can be used for:
- First-factor authentication to enable passwordless sign-in to the User Portal and to SAML or OIDC and OAuth applications.
- Second-factor authentication after user ID and password for the User Portal and SAML or OIDC and OAuth applications.
Limitations
The following are limitations of user certificate authenticators:
- In addition to the IDaaS portal domain
customer.region.trustedauth.com, the network must also allow the SSL service domaincustomer.region.ssl.trustedauth.com. - RADIUS applications and Entrust Identity Enterprise integrations do not support user certificate authentication.
- User certificate authentication must be enabled by an administrator for the application.
Requirements
The following requirements must be met to use a user certificate authenticator:
- Users need the following when authenticating with certificates issued by trusted CAs:
- A user certificate with required certificate components configured by the matching rules.
- A private key for the user certificate.
- A user attribute that maps the user to the certificate.
- Users need the following when authenticating with smart credentials issued by IDaaS:
- An IDaaS-issued smart credential (mobile or physical).
- A connected smart credential and ready smart card reader.
Example use cases
- *Passwordless sign-in. Users select Certificate at sign-in instead of entering user ID and password.
- Step-up authentication. Users first enter user ID and password, then complete certificate authentication as second factor.
How it works
When enabled for passwordless login, users select Certificate on the sign-in screen instead of entering user ID and password. A certificate prompt appears. Available certificates are filtered by trusted CAs and issuing CAs. If the certificate identifies a unique user, that user is signed in.
When enabled for second-factor authentication, users enter user ID and password first, then select User Certificate Authentication. A certificate prompt appears. If the certificate resolves to the same user, sign-in succeeds.
Set up user certificate authentication
- If using user certificates from IDaaS smart credentials, no additional CA configuration is required.
- If using user certificates issued by an external CA, import the trusted CA that issues those certificates. See Configure a Trusted CA, then select Use as a User Certificate CA.
- If using external CA user certificates, configure User Certificate Authentication policy. See Modify user certificate authenticator settings. Smart credential certificates from IDaaS do not use these matching settings.
- Ensure users have required certificate-matching attributes populated in their profiles. See Modify user certificate authenticator settings and Edit, delete, unlock, and disable users.
- Create an authentication flow that allows User Certificate for first-factor (passwordless) or second-factor authentication. See Create authentication flows.
- Create a resource rule for the application. See Create resource rules.
- For the application, select user certificate login under Enable Authentication Flow. See Integrate SAML applications, Integrate OIDC and OAuth Cloud applications, and Edit and delete applications.
Supported certificate components
The following table summarizes supported certificate components.
| Certificate Component | Strength | Comments | Example |
|---|---|---|---|
| securityId (1.3.6.1.4.1.311.25.2) | Strong | S-1-5-21-2162371171-2329155055-2330069595-60558 | |
| uniformResourceIdentifier | Strong | Only URI with format tag:microsoft.com,2022-09-14:sid:<SID> is supported. tag:microsoft.com,2022-09-14:sid: is removed before matching user. | S-1-5-21-2162371171-2329155055-2330069595-60558 |
| commonName | Weak | Alice | |
| userPrincipalName (1.3.6.1.4.1.311.20.2.3) | Weak | alice@example.com | |
| rfc822Name | Weak | alice@example.com | |
| directoryName | Weak | CN=Alice, OU=Users, O=Example Corp, C=US | |
| subjectDn | Weak | CN=Alice, OU=IT, O=Example Company, L=Seattle, ST=WA, C=US | |
| serialNumber | Strong | Hex encoded. Lower case. | 1bb8d278626cd3f6c22ff8951a5e5afe8fc3baf9 |
| SHA256PublicKey | Strong | Hex encoded. Lower case. | 98b8d8a0fa43a8e1fc80ef28861dc2827ed580962f5cf1cd813cffe9fae0b711d |
| SubjectKeyIdentifier | Strong | Hex encoded. Lower case. | 25845de922b61814c873d9eb9604e0871c464a75 |
User matching process
When using only weak identifiers, all weak identifiers must be included and must all match rules match the target user. When a certificate has multiple weak Certificate Components, such as CNs, UPNs, rfc822Names, it is treated as though the certificate does not have that component.
If any strong identifiers are configured, weak identifier matching rules are ignored. Strong identifier matching rules are evaluated sequentially; only the first rule with the lowest order number as strong identifiers should be unique.
Topics in this section
Modify user certificate settings
Use this procedure to configure policy settings for user certificate authentication.