#Security
Posts tagged #Security · 18 posts
- sessionAsSigner: Running XPages Code as the Signer — Who the Signer Is, and Where It Bites
XPages gives you three global session objects: session is the current user, sessionAsSigner is the XPage's signer, and sessionAsSignerWithFullAccess is the signer plus full access. Using it to let a user do what their ACL forbids (write a restricted DB, bypass Readers) is handy — but 'who counts as the signer' is decided per design element, so a script library uses its own signer, not the XPage's, and mixed signatures give inconsistent elevation. This covers the three identities, how the signer is determined, and the setConvertMime / full-access traps.
2026.09.28 - Execution Security Alert: That "Do You Want to Allow" Warning Is the ECL Guarding You
Run an agent, open a mail with a button, click a hotspot — and Notes pops an Execution Security Alert asking whether to allow it. That's not a virus; it's the ECL (execution control list) guarding your workstation. The ECL decides whether a given signer's code may run on your machine and what it can do; a signer not on the list, or one attempting an un-granted action, triggers the alert. This piece covers what the ECL is, why the warning fires, the difference between the workstation ECL and the Administration ECL, its relationship to signing, and how to set it.
2026.09.20 - Put the CA in certstore and Everything Trusts It? DRAPI's Outbound Actually Uses the JVM Truststore, Not certstore
Once a certificate is in certstore.nsf, developers hit two practical questions: how does my service — the Domino REST API especially — serve HTTPS straight from it? And when my own code calls out over HTTPS, does it validate the peer against certstore too? The second answer breaks a common misconception: on one server, certificate trust is actually split across three separate places. Part three of the certstore series, grounded in hands-on testing on Domino 12.0.2, covers DRAPI's keepconfig.d TLSCertStore config, what certstore's trusted roots are really for, and disentangles certstore / Domino Directory / JVM cacerts once and for all.
2026.09.04 - Wiring Domino CertMgr to Let's Encrypt: Automatic TLS Certificate Requests and Renewals over ACME
Manual certificate import still means swapping every 90 days, and still means forgetting. This piece (part two of the certstore series) covers CertMgr's real killer feature: requesting, configuring, and renewing free, trusted TLS certificates from Let's Encrypt automatically over the ACME protocol. Set up the two ACME account profiles (Staging/Production) and Global Settings, walk the request flow and the six things CertMgr does automatically after Submit, understand HTTP-01 vs DNS-01 challenges, and see why the micro CA is test-only, plus ECDSA and key rollover.
2026.09.03 - Getting Started with Domino Certificate Management: CertMgr and certstore.nsf Instead of Scattered .kyr Keyrings
Since Domino 12, TLS certificates no longer live as .kyr keyring files scattered across each server's disk — one CertMgr server task plus one certstore.nsf database manages them all: certificates stored in TLS Credentials documents, private keys encrypted with 256-bit AES, protected by the database ACL, and readable only by the servers you choose. Part one of the certstore series: the model, how to stand certstore.nsf up, what a TLS Credentials document holds, and the full steps to import an existing third-party CA certificate.
2026.09.02 - The Domino REST API Before Go-Live: the Security Model, One-Way Rich Text, CORS, and Admin Ports
Series finale. You can authenticate, expose a scope, CRUD, and query; before handing it to real users, a Domino developer must be sure of two things: does it bypass my Readers-field security, and what will bite in production? The answers: DRAPI is layered security (JWT + scope + Domino's own ACL/Readers underneath), so it doesn't leak — but there are real limits (rich text is one-way out, unconfigured fields are unreachable, same-name forms/views are ambiguous), plus CORS and the admin ports to close before going live. Part six (final) of the DRAPI series.
2026.08.24 - Scopes and Schemas in the Domino REST API: How an NSF Becomes REST Endpoints (Exposing Nothing by Default)
Putting an NSF on REST isn't flipping a switch that exposes everything. DRAPI is secure-by-default: you write a schema (a whitelist of which forms, views, folders, agents, and fields go out), then create a scope (the REST mapping that activates it). A scope's name is the very name the JWT scopes claim recognizes from the last part — and underneath, Domino's ACL and Readers fields still apply. This piece separates schema from scope. Part three of the DRAPI series.
2026.08.21 - Getting 401s from the Domino REST API? Understand Its JWT Authentication and Scopes First
Almost every DRAPI call has to prove who you are. It doesn't use classic session/LTPA — it uses a JWT bearer token: POST to /api/v1/auth with Domino credentials for a token, then send it in the Authorization header on every request. This piece covers logging in for a token, what the scopes/aud claims control, where tokens come from (Domino-signed JWT, external OIDC, idpcat.nsf), and traps like the signing key changing on restart. Part two of the DRAPI series.
2026.08.20 - Who Does Your Agent Run As? Signer, Effective User, and the Error 201 / Readers-Field Traps
Your agent works perfectly when you run it — because you're the admin who signed it. Deploy it as a web agent, or schedule it signed by a service ID, and it fails with Error 201 or silently sees no documents. The cause is identity: a Domino agent runs as someone, and that someone isn't always you. A field report on the signer vs the effective user, how session.EffectiveUserName flips on 'run as web user', the runtime security level behind Error 201, and the Readers-field trap that makes documents vanish.
2026.08.03 - Signing and Encrypting Documents in LotusScript: Sign, Encrypt, and the Save-Order Rule
Domino can sign a document to prove who wrote it and encrypt items so only key-holders can read them — both from LotusScript, and both with a gotcha. This article covers NotesDocument.Sign and the server-agent permission it needs, Encrypt with the mandatory flag-item / Encrypt / Save ordering, per-item opt-in encryption, and why EncryptOnSend is a completely separate thing from encrypting the stored copy.
2026.07.12 - Readers and Authors Fields in Code: Document-Level Security You Set with a NotesItem Flag
Domino's document-level access control isn't a special API — it's an ordinary item with a flag. This article covers creating Readers and Authors fields in LotusScript via ReplaceItemValue plus NotesItem.IsReaders / IsAuthors, the security model (no Readers item = everyone; an item with Readers = only those listed), and the lock-out traps: leave yourself and your agents out of the list and you can hide a document from everyone, including the code that made it.
2026.07.10 - NotesIDVault: Pulling IDs from the ID Vault, Syncing, and Resetting Passwords in Code
The ID Vault is Domino's policy-based facility for centrally storing user ID files. NotesIDVault lets you operate it from code — pull a user's ID file out of the vault, sync a local ID back, check whether someone's ID is in the vault, even reset a vault password. This article covers getting it, the GetUserIDFile / SyncUserIDFile / IsIDInVault / ResetUserPassword / PutUserIDFile methods, its relationship to NotesUserID, and the permission prerequisites for these operations.
2026.06.25 - NotesACLEntry Deep Dive — Programmatic ACL Management in Domino: 7 Access Levels, 20 Properties, Roles
NotesACLEntry represents a single entry (person, group, or server) in a Domino database's Access Control List. This guide covers the NotesACL ↔ NotesACLEntry containment relationship, three ways to obtain an entry, the seven access-level constants from NOACCESS to MANAGER, the UserType property versus the legacy IsPerson/IsGroup/IsServer flags, all twenty NotesACLEntry properties for fine-grained permissions, the Roles mechanism, the mandatory acl.Save behavior, five common pitfalls, and complete CRUD examples — closing the Domino security loop alongside the 14.5 NRPC encryption and trust-store articles.
2026.05.15 - Domino 14.5 Mandated Port Encryption Hands-On — CheckPortEncryption Agent, portenc Commands, and Recovery Paths
Following yesterday's concept piece, this article walks through the official 10-step enablement procedure: upgrade the server address book design, sign the CheckPortEncryption scheduled agent, key Directory Profile fields, server ini values (DEBUG_MANDATED_ENCRYPTION, MANDATEDENC_ACTIVE_REFRESH_TIME), Desktop policy entries (DISABLE_MANDATED_ENCRYPTION), the portenc refresh / show console commands, and how to back out if enforcement breaks something. Pre-14.5 servers get their own behavior section.
2026.05.12 - What That `?` Icon Means in Domino 14.5 — Mandated NRPC Port Encryption Concepts and Modes
After upgrading to Domino 14.5, admins see a new `?` icon in the rightmost column of the server view in the Domino Directory. It's not a bug — it's the compliance indicator for the new Mandated NRPC Port Encryption feature, sitting in its default disabled state. This piece walks the history of NRPC port encryption, what 14.5 actually adds (mandate + monitor), how to read the icons, and the three enablement modes. Hands-on enablement steps are in the follow-up article.
2026.05.11 - Domino 14.5 Changes Where NotesHTTPRequest Loads Trusted CAs From — Read Before You Upgrade
Starting with Domino 14.5, server-side LotusScript NotesHTTPRequest loads trusted root CAs from the Domino Directory by default, no longer from cacerts.pem in the data directory. The Notes client is unaffected, and a notes.ini fallback (NotesHTTPRequest_Use_CACerts=1) reverts to the old behavior — but long term, you should migrate self-signed CAs into the Domino Directory. This piece walks the change, scope, pre-upgrade checklist, and ties back to the 5/7 deep-dive on the NotesHTTPRequest toolchain.
2026.05.10 - DQL Production-Ready: Catalog Maintenance, Permissions, and sessionAsSigner
The two real walls when shipping DQL to production: how the Design Catalog gets maintained automatically (bootstrapping brand-new NSFs, incremental refresh after design changes), and why regular users hit the 'You don't have permission' error — plus the sessionAsSigner / scheduled-agent solutions. The final pattern is verified against Domino 12 production logs, with a production-ready Java helper class to drop in.
2026.05.03 - Domino V12 lets notes.ini hold multiple HTTPAdditionalRespHeader entries
Older Domino releases let you put exactly one HTTPAdditionalRespHeader in notes.ini — a second line silently overwrote the first. HCL added a numbered convention (HTTPAdditionalRespHeader01, 02, …) in V12.0.x so you can ship a full security-header baseline through notes.ini alone, which is the only path that still works when HTTP won't start and the Internet Site documents are unreachable.
2026.04.28