Security features

Domino 14.5 provides the following features and enhancements related to security.

Domino OIDC provider

Domino 14.5 can be configured as an OIDC provider and used to authenticate users and assert identities to OIDC Relying Parties such as Domino HTTP 12.0.2 FP3+, Nomad 1.0.15+, and Verse 3.2.4+ as well as third party applications. See Using Domino as an OIDC provider or details.

Web federated login with OIDC

Domino's Web federated login functionality can now be used with an OIDC provider as well as with a SAML identity provider. See Enabling Web federated login with OIDC for details.

Web login with OIDC enhancements

  • Domino 14.5 now supports "third-party initiated login" via a new initiate_login_uri endpoint as defined by OIDC.Core at /auth/protocol/oidc/login which accepts the iss and target_link_uri parameters. The iss parameter can be used by web portals to determine which provider should be used for authentication. This is sometimes called "IdP-initiated login".
  • It is now possible to configure multiple Trusted OIDC providers for a single Internet Site. When doing so:
    • Automatic redirection of unauthenticated requests to a provider for authentication will use one of the trusted providers. Which provider is used may vary.
    • When automatic redirection is disabled via the OIDC_LOGIN_ENABLE_REDIRECT=0 notes.ini the Domino HTTP server's default session login form will display a "Log in with <provider name>" button for each of the configured providers for that site leveraging the new initiate_login_uri endpoint.
  • Starting in Domino 14.5, Web login with OIDC supports the "form_post" response mode in addition to the default "query" response mode. If the configured Trusted OIDC Provider advertises form_post support in their well known endpoint and the OIDC_RESPONSE_MODE_FORM_POST=1 notes.ini variable is set on the Domino RP, the Domino RP will request response_mode=form_post. Note that the Domino OIDC Provider does not support form_post.
  • Workarounds have been added for two OIDC providers with non-standard requirements. Azure AD B2C requires the client_id in the list of requested scopes which can be enabled via OIDC_LOGIN_ENABLE_AZURE_AD_B2C_WORKAROUNDS=1 and when using providers that reject token requests containing an Authorization header for client_secret_basic and the client_id POST parameter. set OIDC_LOGIN_ENABLE_ROEID_WORKAROUNDS=1

For full documentation on this feature, see Using OpenID Connect (OIDC) to configure federated-identity authentication.

Passkey metadata

Domino can now be configured to download or import and then use FIDO2 metadata in order to identify the authenticators being used to create new passkeys in passkey.nsf. Administrators can also leverage this functionality to select authenticators from the list and explicitly allow or deny their use. See Passkey Authenticator Metadata for details.

Other passkey enhancements

  • The following notes.ini settings have been removed. Their functionality is now controlled through new settings in the Internet Site document's Security tab.
    • PASSKEY_RESIDENTKEY_REQUIRED
    • PASSKEY_REQUEST_DIRECT_ATTSTMT
    • PASSKEY_REQUIRE_USER_VERIFICATION
    • PASSKEY_USE_ALLOWCREDENTIALS
    • PASSKEY_SKIP_LEVEL
    • PASSKEY_DOMAIN_LEVELS

A new setting in the Internet Site document's Security tab, Use only passkeys, can be used with the domcfg.nsf passkey login form to permit passkey authentication only for users with registered passkeys and to strongly encourage users without registered passkeys to create passkeys.

When "Use only passkeys" is enabled, end users with multiple devices should register their first passkey on a roaming authenticator, such as a smartphone or tablet, to make subsequent creation of passkeys on other devices and platform authenticators such as Windows Hello simpler.

For more information on the settings on the Internet Site document's Security tab, see Optional passkey configurations.

Mandated NRPC port encryption

Mandated port encryption can be used to enforce and monitor NRPC port encryption on 14.5 clients and servers. See Enabling mandated NRPC port encryption for details.

LotusScript NotesHTTPRequest

Starting with Domino 14.5 server, the NotesHTTPRequest LotusScript class methods will, by default, load Trusted Roots from the Domino Directory when running on a Domino server. Previously, trusted root certificates were loaded from the file "cacerts.pem" in the Domino data directory. This new change doesn't impact NotesHTTPRequest LotusScript class behavior on the Notes client.

If you prefer to maintain the previous behavior and continue using "cacerts.pem", you can do so by setting the server-side Notes.ini parameter: NotesHTTPRequest_Use_CACerts=1