• 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!
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?
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)
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
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.)
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
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
==> JVM heap for HTTP • JavaMaxHeapsize ==> JVM heap for the rest • Default values for Domino 8.5+ and 64-bit • HTTPJVMMaxHeapSize=1024M • JavaMaxHeapsize=256M
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
• /[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+
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
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