Security features

Domino 14.0 EA2 provides the following features and enhancements related to security.

Sign in to Domino HTTP with passkeys (webauthn/FIDO2)

Domino 14 EA2 introduces authentication with passkey via the WebAuthn/FIDO2 protocol.

See these web articles for helpful information about passkeys:

To sign into Domino HTTP with passkeys:

  1. As an administrator, create the Passkey database passkey.nsf from passkey.ntf and set up replication rules for that database across the set of 14.0 EAP2 servers that will be using passkeys.
  2. Enable Passkeys authentication by setting ENABLE_PASSKEY_LOGIN=1 in the EA2 servers' notes.ini files (Note: We are planning on adding this setting to the Internet Site doc for EA3)
  3. Register a passkey: Launch a modern web browser, authenticate to Domino HTTP, then manually connect to https://domino_server.example.com/webauthn/register.html
  4. Optional: As an administrator, open passkey.nsf to view the registered public keys (passkeys) for each user and Internet Site.
  5. Sign in with a passkey: Launch a modern web browser and manually connect to https://domino_server.example.com/webauthn/login.html

Adding hooks for passkey registration and authentication to more locations is planned for EA3. As always, feedback is encouraged and appreciated.

Enhanced OpenID Connect 1.0 (OIDC) provider support

Whitepapers for ADFS 2019 and Azure AD are now published on the HCL Support site; many of the 12.0.2 notes.ini parameters referenced in those documents map to idpcat fields in Domino 14 EAP2.

Note: These whitepapers describe configuring Domino using the notes.ini parameters used by 12.0.2, not the idpcat template fields used by 14.0. All four of those configurations work with 12.0.2 FP1 (or 14.0 EAP1) except for #3, which requires 12.0.2 FP2 or 14.0 EAP1.

Web user login with OIDC Enhancements

private_key_jwt authentication is now supported. Copy a private signing key in PEM or JWK format into the "client secret" field of the OIDC Provider document, and set the authorization type field to "private key jwt". The corresponding public JWK will be published in jwks_uri format at /auth/protocol/oidc/keys so that dynamic key updates can be supported.

Third-party access token validation

There is a new API that is likely to be exposed in the SDK for 14.0. We are currently seeking feedback before finalizing the API. This would be usable from any server process, and would leverage the trusted OIDC providers configured in idpcat.nsf to validate access tokens.

/* SECValidateAccessToken
 *
 * Validates a signed JWT access token that was generated by a trusted OIDC provider.
 * Intended to be called by multiple different server tasks as well as external code.
 *
 * Inputs: 
 *   pszAccessToken   - Points to the B64url encoded signed JWT to validate
 *   pszProviderURL   - Base URL of trusted OIDC provider for this connection
 *   pszRequiredScope - "Domino.user.all" or equivalent
 *   pszResourceURL   - Expected value in audience (aud) claim, such as https://www.example.com
 *   dwFlags          - Modify behavior from defaults; flags defined and described below
 *   vpOptionalParams - Optional. If non-NULL, must point to a JWT_VALIDATE_OPTIONAL_PARAMS structure
 *   pOptionalParams->pszCustomClaimName
 *   pOptionalParams->ResourceCallback
 *   pOptionalParams->AllowedClientID
 *   dwMaxEmailSize   - Size of retszEmail buffer in bytes
 *   retszEmail       - Points to buffer to receive email address
 *   retdwDurationSec - Optional. Points to DWORD to receive output
 *
 * Outputs:
 *   *retszEmail       - On success, filled in with email address from JWT
 *   *retdwDurationSec - Optional. On success, filled in with seconds left before expiration
 * 
 */

typedef BOOL (*ResourceCallback) (char *pszAudience);
typedef BOOL (*ClientCallback) (char *pAzp);

typedef struct {
    char *pszCustomClaimName;
    ResourceCallback AllowedResource;
    ClientCallback AllowedClientID;
} JWT_VALIDATE_OPTIONAL_PARAMS;

/* Only supported in non-production builds */
#define fJWT_validate_AllowExpired          0x00000001

/* If set, Domino will tolerate standards violations known to be used by Azure AD and ADFS 2019 */
#define fJWT_validate_AllowMSWorkarounds    0x00000002

/* If set, Domino will look for the claim name from pOptionalParams->pszCustomClaimName before the "email" Claim */
#define fJWT_validate_UseCustomEmailClaim   0x00000010

/* If set, Domino will call the pOptionalParams->ResourceCallback for each audience in the "aud" Claim. At least one must be allowed (returns TRUE) for the token to be valid */
#define fJWT_validate_AllowAlternateAud     0x00000020

/* If set, Domino will call the pOptionalParams->AllowedClientID callback with the value of the "azp" Claim. This callback must return TRUE for the token to be valid. */
#define fJWT_validate_EnforceAllowedClients 0x00000040


STATUS FAR PASCAL SECValidateAccessToken (const char *pszAccessToken,
                                          const char *pszProviderURL,
                                          const char *pszRequiredScope,
                                          const char *pszResourceURL,
                                          DWORD      dwFlags,
                                          void       *vpOptionalParams,
                                          DWORD      dwMaxEmailSize,
                                          char       *retszEmail,
                                          DWORD      *retdwDurationSec);

Person Document - Administration - Encryption Capabilities

We added support for Notes document/email encryption with 128 and 256-bit AES (instead of RC2) in 8.0.1, but due to backwards compatibility concerns (users on clients older than 8.0.1 wouldn't be able to read those documents), it was blocked behind a setting that could only be enabled through an Admin client wizard. Also, because the Admin client wizard and our documentation called the functionality "FIPS 140-2 support" instead of "AES support" the uptake of this functionality, outside of our more security-conscious customers, has been very low.

In order to improve the update of the legacy AES document and email encryption support, we have addressed the following points in EA2:
  • 14.0 no longer requires the presence of that person document setting to use AES encryption for a given recipient, as nobody sending encrypted mail from 14.0 is likely to be sending email to someone on a Notes client older than 8.0.1.
  • The wording used in that Admin client wizard has changed from "FIPS 140-2" to "AES", which should encourage more adminstrators to enable that setting.
  • Newly registered user IDs in 14.0 will have that setting enabled by default, so end users running on an older client will see those recipients as AES capable.
  • The default algorithm used for document encryption (including Notes-formatted email) in 14.0 is 256-bit AES
  • Use of the OpenSSL library's FIPS provider is now being accurately displayed in the Document Encryption and Signing Properties dialog.
You can tell what encryption and signing algorithms were used on a document with the "Document Encryption and Signing" button on the bottom of the Notes client to the right of the status bar:
HCL Notes Document Encryption and Signing button with encryption icon


Document Encryption and Signing Properties dialog box

Cluster-safe, sprayable, single-server session cookies (DomAuthSessId)

When enabled by setting the new notes.ini DominoSessionCookieUniqueNames=1 the name of the DomAuthSessId cookie becomes DomAuthSessIdABCDEFGHIJK, where ABCDEFGHIJK is the first 11 characters of Base64url [SHA256 (Domino server DN)]. This causes multiple Domino servers that are all serving the same internet site to choose unique cookie names instead of overwriting each other's cookies. This functionality is disabled by default in EA2, and might remain disabled by default in the final release due to concerns about breaking current applications and sprayer rules with special logic for cookies named "DomAuthSessId".