Security features

Passkey enhancements

Domino 14.5 EA1 and later support using the FIDO Metadata Service to more accurately identify and verify passkeys and their authenticators.

Passkey Authenticator Metadata

Setting the notes.ini PASSKEY_FIDO_METADATA_DOWNLOAD=1 causes the Domino server to automatically download published metadata from the FIDO Metadata Service once per month. Alternatively, administrators can manually download passkey metadata from the FIDO Alliance Metadata Service web page and place the resulting blob.jwt and root.pem files in the Domino server's data directory.

The signed metadata blob is generally updated on the first day of each month. If the FIDO Metadata is present and a matching aaguid is found for the passkey being created, that authenticator's metadata will be used to populate the name of the authenticator and its root certs will be used to verify "Packed" and "TPM" attestations.

Existing passkey documents can be updated by setting the notes.ini PASSKEY_DATABASE_FIXUP=1

Note: Use of the FIDO Metadata Service is subject to FIDO's terms and conditions on the Metadata Usage Terms (for Relying Parties or Service Providers) web page.

Starting in 14.5 EA2, metadata acquired from the FIDO Metadata Service can be viewed via the Metadata view in the passkey.nsf database. Administrators can select one or more authenticators from the view level and use the Enable Selected and Disable Selected buttons to allow or deny creation of passkeys with the selected authenticators. By default, all authenticators are allowed.

Metadata view in Domino Passkey database

Individual authenticators can also make this change at the document level by selecting the Allow authenticator checkbox.

Other passkey improvements

Additional hardcoded authenticator aaguid values were added in EA1 and EA2 and will be used if the FIDO Metadata is not present or the authenticator is not found in the published metadata.
If the notes.ini PASSKEY_USE_ALLOWCREDENTIALS=1 is set, Domino attempts to send the "allowCredentials" claim during authentication. This causes some authenticators to simplify the authentication experience for the end user by assuming that they want to use the same passkey that they most recently used from that web browser. Please note that each browser, operating system, and authenticator might handle the allowCredentials Claim differently, so you might want to test the behavior in your own environment before deciding whether or not this feature is suitable for your environment.
Passkey authentication for users in secondary Domino directories has been successfully tested. Any issues in this space should be reported in the 14.5 Early Access forum so we can collaboratively track down any bugs or misconfigurations.

Domino as OIDC provider updates

Note: The Domino internet site hosting a Domino OIDC provider (OP) must be configured for session authentication. We highly recommend use of single-server session authentication with the DominoSessionCookieUniqueNames=1 notes.ini set. The logout endpoint will not function if LTPATokens are being used, and some forms of token revocation might fail as well. A future drop might remove the ability to configure the Domino OIDC provider on an internet site using multi-server session cookies.

New features or enhancements in EAP Drop 2 are as follows:

IdP Catalog clarification and simplification

The left hand navigation now includes two top-level items: "Trusted Identity Providers" and "Domino OIDC Provider". SAML Relying Party configuration (formerly "SAML Configurations") can be found under "Trusted Identity Providers / SAML." OIDC Relying Party configuration (formerly "OIDC Providers") can be found under "Trusted Identity Providers / OIDC." The "Domino OIDC Provider" view shows all of the configured Domino OIDC providers in this idpcat database, and the OAuth clients registered for those OIDC providers can be found sorted by Client name or by Provider name in the "Registered OAuth Clients" and "Clients by Provider" views.

Multiple Domino OIDC providers

It is now possible to configure multiple Domino OIDC providers in the same idpcat.nsf database. Each OP must be configured on different internet sites with different DNS host names.

Failover cookies

Domino HTTP endpoints hosting the Domino OIDC provider will now issue a signed and encrypted FailoverCookie in addition to the DomAuthSessId cookie. This cookie is used to authenticate the end user against other Domino servers hosting the same Domino OIDC provider to prevent the end user from needing to re-authenticate every time they fail over to a different Domino server. FailoverCookies will be revoked and erased by the OP's logout endpoint.

Refresh token rotation

Refresh token rotation per the refresh token extension endpoint section of The OAuth 2.1 Authorization Framework has been implemented in 14.5 EAP Drop 2. If a refresh token is replayed against the token endpoint, all of the active refresh tokens associated with that authorization grant will be revoked.

Logout endpoint and back-channel logout

The logout endpoint (end_session_endpoint) is functional in EAP Drop 2. End users redirected to that HTTP endpoint can be logged out via their DomAuthSessId session cookie, their FailoverCookie, or their id_token_hint.

If an id_token_hint is not provided, the end user will be prompted to confirm that they wish to log out. Back-channel logout requests will then be sent to all of the OAuth clients with configured back-channel logout URLs associated with this login session. After a successful logout operation, the user agent can be redirected to one of the registered post-logout URIs.

Cross-origin resource sharing (CORS)

CORS support has been added to Domino 14.5 EAP Drop 2. The public openid-configuration and jwks_uri endpoints include a CORS of "*", and one or more specific Allowed web origins can be configured for each registered OAuth client in the field by that name.

Initiate login endpoint (relying party)

A new endpoint /auth/protocol/oidc/login can be invoked on Domino internet sites that are configured for web login with OIDC. This endpoint supports GET and POST requests, supports the standard "iss" and "target_link_uri" parameters, and is intended for integration purposes with web portals and external OIDC Providers.

For the latest documentation, see Using Domino as an OIDC provider.

Web federated login with OIDC

A new feature, Web federated login with OIDC, allows Verse users to perform secure mail operations such as signing and decrypting messages without being prompted for a Notes ID password.

For more information, see Enabling Web federated login with OIDC.

Mandated NRPC port encryption update

To enable this feature (introduced in EAP Drop 1), it is no longer necessary for all 14.5 servers to have "DISABLE_MANDATED_ENCRYPTION" and "DISABLE_OUTBOUND_MANDATED_ENCRYPTION" set to 0. See the updated documentation here: Enabling mandated NRPC port encryption.