Security updates

Security features and enhancements in Domino 14.5.1 Early Access Drop 1.

Support for AES encryption in Desktop policy settings

Local Encryption settings under the Desktop Settings document now support both AES-128 and AES-256 encryption options. For more information, see step 8 in Specifying Preferences for a desktop policy.

New for Web Login with OIDC

  • Multiple concurrent authentication attempts made by the same browser against the same internet site can now all complete successfully. In previous releases, each new authentication request's web login cookies would overwrite the cookies set by the previous request, but starting in 14.5.1 EAP1 the web login cookie names are now tied to their specific authentication request.
  • Improved error handling: Many error paths that returned a 500 response code and an html error page in previous releases will now correctly return a 40x response code with a JSON-encoded response body including an error and error_description.
  • Web Login with OIDC will now request the profile scope by default. To disable this, set OIDC_LOGIN_REQUEST_PROFILE_SCOPE=0
  • We have received reports of an OIDC provider that cannot be configured to return the email Claim in an id token. In order to support this and similar providers, EAP1 adds a new notes.ini variable (OIDC_LOGIN_CUSTOM_CLAIM_NAME) that can be used to configure a custom Claim name to be used in place of the email Claim for id tokens. For example, setting OIDC_LOGIN_CUSTOM_NAME_CLAIM=sub would result in the sub (Subject) Claim being used instead of the email Claim to identify the user being authenticated.

New for Federated Login with OIDC

  • The ID vault server in 14.5.0 supported only a single Trusted OIDC provider; Domino 14.5.1 EAP1 ID vault servers now support multiple Trusted OIDC providers.
  • Please note that configuring multiple hostname-style "tags" in the "Bearer token (JWT) approved OIDC provider configurations" field is not supported. A single tag starting with "bearer.vault." should be configured in idpcat, and that tag in turn can be placed in the "Host names or addresses mapped to this site" field of multiple Trusted OIDC Provider documents.
  • Vault scopes that include spaces and slashes are now supported. Any space characters in the vault scope should be replaced with the underscore ('_') character when configured in idpcat Trusted OIDC Provider and Registered OAuth Client documents. This enhancement only requires upgrading the ID vault server and was also backported to 14.5.0 FP1.

New for HTTP bearerAuth with OIDC

  • Trusted OIDC Provider documents in idpcat.nsf have a new field "Custom full-access scope" that can be used to customize the required scope that grants an access token the user's full access from the default of Domino.user.all. This configuration was backported via a notes.ini to 14.5.0 FP1.
  • The OIDC_ALLOW_ACCESS_TOKEN_WITHOUT_SCOPE=1 notes.ini variable can now be set to entirely ignore a missing scope Claim in an access token. Since ignoring missing scope Claims can reduce the security of your environment, we recommend only setting this variable when using a provider that refuses to send the scope Claim, such as Microsoft Entra ID when using the M2M (client credentials) flow.
  • Testing has confirmed that users' Notes DNs can be successfully used in place of their internet email address as the user identifier in access tokens.
  • The existing SDK API SECValidateAccessToken() can be called with a new flag that allows passing the "host name" from the Trusted OIDC Provider document in the pszProviderURL parameter. Note that as of 14.5.1 EAP1 this host name must have been previously loaded from idpcat into the cross-process cache to be used. See inc/bsafe.h in the SDK for details.

New for the Domino OIDC Provider

  • The duration of the end user's login session with the Domino OIDC provider is now configurable via a new field in the "Domino OIDC Provider" document in idpcat.nsf. Please note that the Domino server should be restarted after any changes to Domino OIDC Provider documents or Internet Site documents. The default value of this field is 18 hours. This field determines how long the user's FailoverCookie will remain valid, and does not impact the maximum session lifetime configured for Registered OAuth Clients, which determines how long new refresh and access tokens can be acquired from a single authorization grant for a given client.
  • The OIDC provider's key rotation functionality has been hardened to help prevent accidental misconfigurations.
  • The authorization endpoint now supports the "prompt=none", "prompt=login", "prompt=consent", and "max_age=<seconds>" parameters per OIDC.Core.
    • prompt=none will result in a 302 error response being returned to the client's registered redirect_uri if the authorization request would have required user interaction for either authentication or consent.
    • prompt=login will force the end user to log in again, even if they have a currently valid login session with the OIDC provider.
    • prompt=consent will force the user to re-grant consent for the client application.
    • max_age=<number of seconds> can be used by a client that wants the user to be prompted for authentication again if their current login session at the OIDC provider is more than <number of seconds> old.
  • The configured redirectURI field in the Registered OAuth Client document now supports dynamic ephemeral ports when using the loopback device per RFC 8252 sections 7.3 and 8.3 to better support mobile and native clients. A configured loopback redirectURI in the pattern of "http://127.0.0.1/my/redirect/uri" will now match against any dynamic port "http://127.0.0.1:{port}/my/redirect/uri". Note that the OAuth client will need to send the full redirect URI, including the port in the redirect_uri parameter, and that the registered redirectURI must begin with "http://127.0.0.1/". Per the RFC, neither "https" nor "localhost" will be accepted with dynamic ports.
  • Domino 14.5.1 EAP1 now supports the use of @Functions in Dynamic custom claims (see the section that follows) and limiting access to Registered OAuth Clients.
  • The Domino OIDC provider now logs many successful and failed operations into log.nsf .

Dynamic custom claims

The Domino 14.5 OIDC provider supported configuring any number of static custom claims and one dynamic custom claim via notes.ini parameter. In 14.5.1 EAP1, this functionality has been completely replaced with a more powerful and more flexible system that allowed admins to configure any number of custom claims that can use AtFunctions to dynamically build claim values. These custom claims will be configurable via a new field in the Registered OAuth Client document in idpcat.nsf for GA, but in EAP1 these claims require the OIDC_PROVIDER_CUSTOM_CLAIMS notes.ini. Individual claims must be separated by the tilde '~' character.

Table 1. Notes.ini settings for dynamic custom claims
Notes.ini Description 
OIDC_PROVIDER_DYNAMIC_CLAIMS=tid=1234~foo=bar
 Set the "tid" and "foo" Claims to fixed values. 
OIDC_PROVIDER_DYNAMIC_CLAIMS=emp=@Text(EmployeeID)
 Set the "emp" Claim to the value of the "EmployeeID" field in the user's person document. 
OIDC_PROVIDER_DYNAMIC_CLAIMS=org=@Name([O]; 
FullName)~domain=@Right(InternetAddress; "@")
 Set the "org" and "domain" Claims by parsing the FullName and InternetAddress fields from the user's person document. 
OIDC_PROVIDER_DYNAMIC_CLAIMS=emp
=@Text(EmployeeID)~tid=1234~foo=bar~org=@Name([O]; 
FullName)~domain=@Right(InternetAddress; "@")~abbr
=@Name([ABBREVIATE]; FullName)~canon
=@Name([CANONICALIZE]; FullName)~namewithdept
=@Name([CN]; FullName) + " (" + Department + ")"
 Set a wide variety of fixed and dynamic claims based on the user's person document.
Note:
  • In EAP1 since custom claims are configured through Notes.ini settings, the custom claims will be added to all of the access tokens and the id tokens returned by the Domino server. When this configuration moves to the "Custom Claims" field in the Advanced section of the "Registered OAuth Client" document in idpcat.nsf in a future drop, custom claims will be configurable per-client.
  • The HTTPPassword may not be used in custom claims, and excessively long custom claims may be truncated.

Limiting access to registered OAuth clients

Most Domino environments perform access controls at the resource being accessed through ACLs, reader and author fields, and so on. However, some third-party applications prefer to have their OIDC provider perform access checking and deny unauthorized users the ability to acquire an authorization grant for their application.

In order to support this scenario, Domino 14.5.1 EAP1 added an Allowed user group field to the Advanced section of Registered OAuth Client documents in idpcat.nsf. By default, this field is blank and all authenticated users are allowed to acquire authorization grants for this client.

To limit access, add the name of a group containing the users who are allowed to use this client into the Allowed user group field on the primary Domino OIDC provider server and save the document. The primary Domino server will immediately process this change and replicate it out to the secondary OIDC provider servers with no restarts or manual replication required.



New Session method (Java) for Domino OIDC provider

A new Session method (Java) is added for acquiring an access token from the Domino OIDC provider. For more information see getOIDCAccessToken (Session - Java) in the Domino Designer documentation.

Domino OIDC provider support for Verse mobile clients

Configuring HCL Verse Mobile and HCL Traveler with OIDC allows Verse Mobile users to authenticate through Domino as an OIDC provider prior to accessing the HCL Traveler services. For more information see Configuring Verse Mobile with OIDC login.

Support for proxies between Domino and the OIDC provider

Starting in 14.5.1, Domino's Web Login with OIDC and bearerAuth features now support authenticating web proxies to mediate outbound traffic that previously prevented Domino servers from contacting their trusted OIDC providers.

In the IdP Catalog database (idpcat.nsf), there is a new section at the end of the "Trusted OIDC Provider" document labeled "OIDC Outbound Proxy Configuration." Administrators have the option to populate the fields in this section with the URL for the outbound web proxy, as well as the user name and password if any is needed to authenticate to that proxy.


Fields for configuring OIDC outbound proxy

CertMgr improvements

New for Passkeys

Automatic Passkey Upgrades

Administrators can now enable automatic, opportunistic upgrades to passkeys via WebAuthn's new "Conditional Create" API. In names.nsf, open the Internet Site document, navigate to the Security tab, scroll down to the Passkey Settings section, and set Automatically create passkeys to Yes.



This setting will ask the user's default password manager to opportunistically create a passkey for the end user immediately after authenticating that user to the site using a user name and password that was saved in that password manager. The user will receive a non-disruptive notification in their client if the upgrade succeeded and will see nothing if it failed. This functionality is still relatively new and is not supported by all web browsers, password managers, and operating systems, but where supported it can significantly simplify the process of upgrading end users from passwords to phishing-resistant, innately multifactor, easy- to-use passkeys.

Note: For more information about automatic passkey upgrades, see the following references from the Chrome/Apple developer sites:

Improved Passkey Management

End users can now manage their own passkeys in the Passkey database by selecting the Create or manage passkeys checkbox when logging in to the Domino HTTP server. This new user interface will allow end users to view and manage all of their registered passkeys for a given internet site. Note that a user's final passkey cannot be deleted to minimize the risk of the end user accidentally locking themselves out of the server.

Domino will now return passkey creation and management endpoints from the new passkey well-known endpoint (https://www.example.com/.well-known/passkey-endpoints) as defined by the W3C working draft in A Well-Known URL for Relying Party Passkey Endpoints if the RP ID matches the Internet Site name. For example, if the configured RP ID for www.example.com is example.com, the well-known endpoint will not be returned, but if the configured RP ID for www.example.com is www.example.com, it will be returned. Credential providers and password managers can query this standardized endpoint and allow end users to create new passkeys and manage their existing passkeys for a site from within their own user experience.

Keep Passkeys Up to Date

One of the concerns that some people have with passkeys is related to the inability of servers to communicate changes back to the authenticators holding those passkeys. These concerns have been addressed with three new WebAuthn Signal APIs that Domino 14.5.1 EAP1 will use by default to keep information in authenticators synchronized with information in Domino's Passkey database (passkey.nsf) When a user changes their name or email address in Domino, the signalCurrentUserDetails API is used to inform the authenticator of the update. When a user attempts to authenticate with a passkey that was deleted from passkey.nsf, the signalUnknownCredential informs the authenticator that the credential is no longer useful. Finally, after a user authenticates to Domino with a passkey, Domino uses the signalAllAcceptedCredentials API to inform the authenticator of the current set of valid credentials for that user so the authenticator can remove any no-longer-accepted credentials for that site.

Note: The WebAuthn Signal APIs are currently supported and functional with authenticators such as Google Password Manager and Apple Passwords (available from Safari 26 onward on macOS). The Signal APIs are relatively new and still rolling out, with broader support expected across more platforms and authenticators soon.