I'm pretty rusty on what I know of SAML, but as I recall, SAML isn't so much a mechanism as it is a protocol. I'd be less worried about Tomcat supporting it and more concerned about what your Tomcat clients would be able to do with it.
Tomcat itself supports
JEE standard security via 4 primary components: First, you have the Realm itself, which deals with authentication and authorization. Then you have the UserPrincipal, which hangs off the HTTPServletRequest object. Then you have the HttpSession, which anchors the security components between request/response cycles. And finally, you have the jsessionid, which is the key into Tomcat's HttpSession map used to find which HttpSession corresponds to which client. The jsessionid is simply a short hash code, with no inherent meaning, and in fact, it cannot be cached on the client, because it can be and is changed by the JEE server on any given request - the HttpSession is simply assigned a new key in the server's session map.
So in the non-SSO security environment, every Http(s) request that comes into Tomcat is mapped to an application, and that application's
web.xml generates a security
pattern map (when annotations are used, they just get added to the actual web.xml in-memory component).
When a URL matches a security pattern, Tomcat checks to see if there was an accompanying jsessionid, either as an appendage to the URL itself (";jsessionid=xxxx") or in a cookie named jsessionid. If so, that jsessionid is used to find the user's HttpSession, which in turn finds the security conntext, allowing the user's assigned security roles to be checked to see if they allow access to that URL.
If there is no jsessionid, the user isn't yet signed on and Tomcat will "park" the request and send back a login screen (FORM-based login) or signal the need for a client login dialog popup (BASIC login). The user provides credentials and they are passed as arguments to the Realm's "authenticate()" method. It returns a go/no go response. For "no go", you get loginfail action until the user provides valid credentials or gives up. For a "go", the authentication mechanism ensures that an object implementing the UserPrincipal interface is constructed and supplied to Tomcat, which will then create an HTTPSession if one did not already exist and attach the UserPrincipal to the HttpSession.
Once authenticated, Tomcat can "un-park" the original URL request and vet it against the Realm Authentication. It does this by looking up the role(s) mapped to the URL in the webapp's web.xml security elements and invoking the Realm's "isUserInRole()" method, which again, returns a go/no-go response. Note that good security never volunteers information, You can't "fish" for roles, only determine if a role fits.
Now we know if we're passed the tests. If not, Tomcat will invoke the "403 - Forbidden" response for the webapp. Otherwise the URL gets parsed and passed to the servlet or
JSP that web.xml/Tomcat has mapped to that URL. Tomcat has a default web.xml built into it for things like JSPs, page indexes and static context that it uses for stuff that the webapp's own web.xml doesn't handle. Normally you'll never touch this.
The net effect is that loging/authentication is completely transparent, functionally. The webapp cannot tell whether the user just logged in or not — there is no "login/logout" event to listen to. The only difference to a servlet/JSP of a logged-in user and a logged-out user is whether the getUserPrincincipal() and getRemoteUser() methods return data or null.
So what about SSO? This is one of the reasons that Tomcat has no login events. With SSO, you could have logged into the SSO system from some other app on some other server, a half-hour ago. In this case, Tomcat needs a Realm that can check with the SSO security server and construct its internal security objects accordingly. To be fully transparent, the Realm you use should itself be able to log in to the SSO security server in case SSO had not been done elsewhere.
For something that does SSO based on your Windows LAN signon, the Kerberos ticket that Windows creates when you log into Windows can be used to avoid a login prompt, as the Realm will use that. For other systems, you just need to have some sort of extra-Tomcat security environment that can be tapped into. In your case, that would be whatever Domino uses, and if memory serves, Domino uses web clients these days, unlike when I had to have a separate Lotus Notes desktop application. So see what it's using.
As a final note, another SSO options is OAUTH2, which Tomcat also supports. OAUTH2 can be a pain, since it's hard to automate something that really wants manual participation, but it's well-supported.