TIPS AND TRICKS FOR DEVELOPERS Approved for Test and Development Servers only!

AUTHENTICATION MECHANISMS • Mostly, we don’t really care… • However… • Customised Login/Logout • Simulating the same authentication scheme • Apps providing service for “weirdies” • Many options: • Basic Authentication • Session Authentication (Single Server vs Multi-server) • SAML, OAuth, IAM, etc. ==> Not today!

AUTHENTICATION: BASIC HCL Domino Server Browser Request: GET /path/database.nsf Response: 401 Unauthorized WWW-Authenticate: Basic realm=“/path” Request: GET /path/database.nsf Authorization: Basic SXQncyBiaWdnZXIgaW5zaWRlIQ== Response: 200 OK

AUTHENTICATION: SESSION HCL Domino Server Browser Request: GET /path/database.nsf Response: 200 OK Login Form (text/html) Request: POST names.nsf?Login Form Data with UserName + Password + RedirectTo Response: 200 OK Target Content + Authentication Cookie 401?

SINGLE SERVER VS. MULTI-SERVER • Single Server • Server creates a cookie “DomAuthSessId” • Server keeps a list of authenticated sessions • Cookie is only valid for single server • Multiple servers (SSO) • Server creates a cookie “LtpaToken” (customizable) • Token is hashed with the username and expiration time • Multiple Servers share a secret key to hash/verify the token. • Server doesn’t keep track of users (except for monitoring)

DIFFERENCES Basic Single Server Multi-Server Name of the Cookie: No cookie DomAuthSessId LtpaToken (Configurable) Expiration is kept… On Browser On Server On Cookie Timeout depends on… Browser Session Last request Cookie Creation tell Http Show Users None Accurate Inaccurate On HTTP Restart Continue Need Authentication Continue

SOME TIPS ON AUTHENTICATION • When Session Authentication is enabled, • Unauthenticated/unauthorized requests returns “200 OK” • 401/404 expected in modern web architecture • Tip: Override Session Authentication • Multi-server session cannot be extended, token cannot be canceled. • Tip: Remove LtpaToken cookie for manual logout • Tip: Keep the expiration time long enough • XPages Session ≠ Authentication Session • XPages session ~ SessionID cookie • Specific to the browser session

TIPS FOR XPAGES DEVELOPERS • Always use Internet Sites! • Additional settings • Multiple domains • More practical for testing • Enabled from the server document • Need site document for all protocols (e.g. IMAP, POP3, SMTP, etc.)

TIPS FOR XPAGES DEVELOPERS • Allowed methods and Domino Access Services • Relevant Internet Site Document \ Configuration • Important for RESTful developers

TIPS FOR XPAGES DEVELOPERS • Server-wide xsp.properties • Go to “[domino-data]\properties” on the server • The sample file is the documentation for all properties.

TIPS FOR XPAGES DEVELOPERS • XPages app connecting to a remote server • XPages as a front-end application layer • Data in another NSF, even in another server • “Trusted Servers” will be useful! • It’s not for production • Low performance • Great to access real data from the production

TIPS FOR XPAGES DEVELOPERS • Debugging HTTP Thread • tell http debug thread on | off ==> Default level • tell http debug postdata on | off ==> for client POST data • tell http debug responsedata on | off ==> for server response data • Save some space! • tell http debug lastonly on | off ==> Keep only the last request! • For more options… • https://support.hcltechsw.com/kb_view.do?sysparm_article=KB0032210

TIPS FOR XPAGES DEVELOPERS • Use XPages Log File Reader from OpenNTF • https://www.openntf.org/p/xpages log file reader • Send your virtual kudos to Jakob Majkilde!

JVM CUSTOMIZATION • notes.ini parameters for JVM Memory • HTTPJVMMaxHeapSize ==> JVM heap for HTTP • JavaMaxHeapsize ==> JVM heap for the rest • Default values for Domino 8.5+ and 64-bit • HTTPJVMMaxHeapSize=1024M • JavaMaxHeapsize=256M

JVM CUSTOMIZATION • Add JVM arguments via notes.ini • Create a text file with JVM arguments • JavaOptionsFile=c:\path\to\jvm.txt • Very useful to customize JVM! • Testing different locales • Setting TLS protocols • Additional debugging • Tweak third party libraries

JVM CUSTOMIZATION • Modify Java security policy (like a pro!) • /[domino]/jvm/lib/security/java.policy ==> do not use! • /[user-home]/.java.policy ==> will persist! • What is [user-home]? • Linux: /local/notes (notes is the user for domino service) • Windows (Run as a service): C:\Windows\System32\config\systemprofile • Windows (Run as an app): C:\Users\JANE.DOE • Technote: • https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0085173 • Reminder and Correction: • /[domino]/jvm/lib/security/java.pol ==> Obsolete as of R11+

SECURITY TIPS • Careful with the HTTPEnableConnectorHeaders • Normally, it should be “0” • It allows an attacker to impersonate any user! • Only for “behind the proxy” scenarios. • In case, Domino HTTP should be secured with Firewall. Image is from Wikipedia. Refer to Jesper Kiaer for more details. https://nevermind.dk/nevermind/blog.nsf/subject/security-hole-leaves-ibm-domino-server-wide-open---part-one

SECURITY TIPS • Use a different Domino domain for Test/development servers • Testing and UAT servers are wide open for breaches! • Open relay attacks • Insecure passwords for test users • Remote debugging (XPages/Agents) • Intel about production

Q&A TIME!