Authentication Security Levels
The challenge/response security model described so far using names and passwords can actually be deployed using different security levels.
Low Security: basic authentication or anonymous access Medium Security: session authentication and single sign-on
High Security: SSL and X.509 certificate
Low Security
If your requirements for security are very low, you may wish to consider allowing anonymous or "basic name and password authentication" access to the Domino
server. If a user requests access to a database requiring authentication, Domino sends a 401 response, "unauthenticated user". The browser will prompt the user
for credentials with a generic dialog box.
Those credentials will be passed to the server in the HTTP header encoded in base64 format. For each page requested, the HTTP header containing
credentials will be sent. The characteristics of basic authentication make it very insecure for the following reasons.
1. Authentication credentials are repeatedly passed throughout the session
making the credentials especially susceptible to network sniffing.
2. The credentials are not encrypted. They are encoded, but base64 encoding is easily reversed and read.
3. User names and passwords are cached on the browser side and will be remembered until the browser is shut down. Any user who leaves the browser
up after providing credentials is leaving the session open for anyone else to access the server without providing credentials.
It is also important to note the "realm" against which authentication is taking place. A realm is a text string indicating the path or directory for which a user has
been authenticated. If the user requests access to a database that is not in the same directory or a subdirectory, the server will prompt the user to authenticate
again. This could be quite annoying for the end user. This problem can be solved by implementing "Session Authentication" as explained later in the Medium
Security section.
Enabling Basic Authentication and Anonymous Access
By default, port 80, basic name and password authentication, and anonymous access are enabled for access to Domino. When the server is originally
configured, the administrator will have the option to enable or disable anonymous access to existing databases and templates. For better security, select to disable
anonymous access to existing databases when initially configuring your server.
This will prevent unintentional anonymous access to important databases that are included by default such as the directory and log files. You can always go back
and add anonymous access as necessary to individual databases.
The setting for port 80 can be viewed and edited in the server document of the Domino directory on the Ports-Internet Ports-Web tab.
The settings for basic name and password authentication and anonymous access to the server can be found on the Security tab of the Internet Sites document in
the Domino directory. This document is new to version 6.x of the Domino server.
Many of the settings now found in the Internet Sites document of the Domino server were formerly found on the Ports-Internet Ports-Web tab of the server
document. (By default, the settings in the Internet Sites document apply to all servers in the Domino domain.) The following screen shot displays anonymous
and basic authentication settings on the Internet Sites document.
If you want to completely disable anonymous access to the servers in the Domino domain, change the anonymous field in this section of the Internet Sites document
to "No".
The Domino domain web servers can be set up to allow anonymous connections only to particular databases. For this to work, leave anonymous access set to
"Yes" in the Internet Sites document and permit or deny anonymous access to particular databases by using an Access Control List (ACL).
The screen shot below displays the ACL on a Domino database. This ACL does not allow anonymous access. If a user tries to access this database with a
browser, the user will be prompted to authenticate. It is important to note that if you do not have the "Anonymous" keyword in the ACL, anonymous users will
have whatever access the "Default" user has. If allowing anonymous access to the server, it is very important to review the ACL's on all databases for
anonymous and default keywords to ensure anonymous access is only permitted as intended.
Medium Security
A feature called "Session Authentication" can be enabled per each single server or for multiple servers. Session Authentication provides an increased level of
security over basic authentication for several reasons. When Session Authentication is enabled, the user is presented with a log-on form similar to the
display below.
The basic logon form can be found in a database called "domcfg.nsf". The Integrum customised login form is located in the resourcelib.nsf of the clients instance.
Once the user enters proper credentials into the log-on form, Domino encrypts the password and stores it in a cookie, and the cookie is used for subsequent access.
The following aspects of session authentication additionally enhance security and provide ease of use.
1. The server has knowledge of who is using the server so you can get a listing of active users. To see such a list, just access the server console and type
"tell http show users".
2. Because the server is maintaining state with a cookie and has knowledge of user activity, sessions can be timed out after a specified period of inactivity.
The cookie is simply set to expire after a specified period of time. The administrator can configure the time-out as described below.
3. A developer can easily create a log out button. Users can click the log out button to destroy the server side-state and clear the session without closing
the browser.
4. The credentials are only passed to the server in clear text when initially entered, reducing the likelihood that credentials will be sniffed. (Please read
"Important Tip" in the High Security section for information about encrypting credentials.)
5. Security policy banners can be appropriately displayed. To enable session authentication, open the Internet Sites document and select
the Domino Web Engine tab. Change the Session authentication field from "disabled" to "Single Server". You can also set the "Idle session time-out" here.
The default timeout value is 30 minutes. (Note: Basic Authentication as described above must remain enabled for Session Authentication to work.)
High Security (Integrums preferred solution)
For maximum security, consider enabling Secure Sockets Layer (SSL) protocol. SSL is a security protocol that can provide a higher level of security for basic or
session based authentication. SSL can also be used to increase the security of anonymous connections by requiring client authentication. Additionally, SSL can
provide confidentiality and integrity. Domino supports SSL and uses industry standard X.509 certificates in its implementation.
SSL consists of two sub-protocols, the SSL record protocol and the SSL handshake. The SSL record protocol specifies the format of messages
exchanged between the client and the server. The format includes a message digest, created using the MD5 algorithm, to ensure that messages are not altered,
thus providing integrity. During the SSL handshake, the client and server can authenticate each other using certificates and public keys. Also during the
handshake, the client and server cooperate to create symmetric keys for the session used to perform encryption that provides confidentiality. (Introduction to
SSL).
SSL Authentication
An essential step in implementing SSL is to obtain signed certificate from a Certificate Authority (CA). Initially, a certificate request is issued by the subject
(client or server) and submitted to the CA for verification and signing. A Certificate Authority is (usually) a third party organization that signs and issues unique digital
certificates to company or individual. The CA performs a background check to confirm the identity of the certificate requestor. The background check for
companies is typically more thorough than the check done for individuals. Once the background check is completed, a Certificate containing a serial number and
information about the CA and the subject (server or individual requesting the certificate) is signed and issued by the CA. The Certificate is installed as
appropriate on the server or the browser client.
Exactly how does server authentication occur, and why does it matter? If a browser has a trusted or root certificate signed by the same Certificate Authority
(CA) that signed the server certificate issued by the CA, then the client can be sure the server is who it says it is. This prevents a third party machine from
spoofing the machine that you intended to connect to. That could be critical, for instance, if you were sending a credit card number to a bank's web server. You
would want to be certain you were sending the credit card number to the bank's server and not an imposter.
Enabling SSL on Domino
You can enable SSL for the entire server, or for any particular database. First you must activate the SSL port in the server document. This is done on the Ports -
Internet Ports - Web tab of the server document.
Next, open Security tab on the Internet Sites document to further define how SSL will be used. On this document, you can enforce all TCP connections to use SSL
by selecting "Yes" in the "Redirect TCP to SSL" field. Further, you can specify whether anonymous or name and password authentication will be accepted for
SSL connections and whether client authentication will be used.
Choosing A Certificate Authority
Integrum uses DigiCert & RapisSSL for all their server SSL installations.
If a client uses their own domain name for the Integrum application, Systems Admin will need to generate a CSR and send it to the
client who in turn will generate a server certificate from their internal CA server.
The will then need to send the server certificate, root & intermediate certificate back to Systems Admin who will then create a SSL key and apply it to their instance.
Authentication with SAML
SAML Terminology
IdP – Identity Provider
-Oracle Identity Manager
-IBM Tivoli Federated Identity Manager
-Microsoft Active Directory Federation Services
SP – Service Provider
-Your Domino Server
Assertion – What the IdP tells the SP
SAML Benefits
A single trusted, authoritative source is used to authenticate users who then need access to resources on multiple servers
-often outside the control sphere of the authoritative source.
Allows third parties to provide services to a user community, while management of that community remains centralized.
Highly flexible security and meta data capabilities allow a wide range of interoperability
SAML in Domino
Domino acts as both an SP & IdP
Currently only supports two IdP Products (Others work but are not supported yet by HCL)
-Microsoft Active Directory
-Tivoli Federated Identity Manager
There are reports of it working with others
-Most common IdP I’ve seen is Oracle Federated Identity
•add on to Oracle Identity Manager
Requires a Notes ID and Person Document for all federated Notes Client users
-but not necessarily browser access users
Requires the use of ID Vault if used for Notes Client federated login
First get the metadata file & x.509 from the IdP
Typically this is going to be “idp.xml” or “metadata.xml”
Warning – Some IdPs will give you an invalid XML file!
If the XML file they give you has line feeds in it, so it formats well when you open it in a text editor, it is quite probably broken.
The x.509 public key certificate should be in .cer format
-Typically base64 encoded text