IBM Support

Open Mic Webcast: Configuring an IBM Domino Web server to use SAML-based single sign-on - 14 August 2013 [Presentation, Audio Recording and Q&A attached]



On August 14, 2013, members of the IBM Domino Support and Development teams shared their tips on configuring an IBM Domino Web server to use SAML-based single sign-on.

Attendees were given an opportunity to ask a panel of experts some questions. The call was recorded and slides were made available.

Follow highlights from these Open Mics live on Twitter using #ICSOpenMic or following us on Twitter @IBM_ICSsupport.


Topic: Configuring an IBM Domino Web server to use SAML-based single sign-on

Day: Wednesday, August 14, 2013
Time: 11:00 AM EDT (15:00 UTC/GMT, UTC-4 hours) for 60 minutes

For more information about our Open Mic webcasts, visit the IBM Collaboration Solutions Support Open Mics page.



Audio recording

Configuring an IBM Domino Web server to use SAML-based single sign-on Open Mic Aug 14 2013 (edited).mp3Configuring an IBM Domino Web server to use SAML-based single sign-on Open Mic Aug 14 2013 (edited).mp3


Hide details for Audio Q&A Audio Q&A
Audio Q&A

Q: Is mail the only attribute to map users or is it possible to use other attributes as well, e.g. EmployeeID or UID?

A: The SAML assertion is created by the SAML IdP and the SAML IdP is the component that's responsible for authenticating the user perhaps by transparent mechanisms such as SPNEGO or KERBEROS or by asking the user for the username and password. So the IdP knows who the user is and prepares the SAML assertion which includes the user's email address and that SAML assertion will come over to Domino. Domino will cryptographically verify that the SAML assertion comes from a trusted IdP and will find the user's email address inside the SAML assertion. Domino will look up the user's email address in Domino Directory or possibly in other LDAP directories known to Domino via Directory Assistance. then that email address must map to one and only one Domino distinguished name. So in the Domino Directory we have the Internet Address field which includes the user's email address and in a directory such as Active Directory usually that attribute would be called the "mail" attribute, so those two fields of the directory would need to reflect the same user. If there was any confusion from the Domino standpoint as to who this user is based on the email address that comes in the SAML assertion, then the user would not be authenticated at Domino.

Q: I have a question concerning other IdPs. What are the plans for supporting other IdPs, specifically Shibboleth, which is very widely used especially in University networks. Do you think it will work?

A: We do expect that customers will deploy IdPs other than ADFS or TFIM but they are not officially supported by Domino. We have heard some feedback that certain IdPs do work, although we are not going to guarantee that they work because we haven't tested them. Because SAML is an industry standard, and we are adhering to standards, if these IdPs adhere to the same standards and they don't break any of the standards, it's likely that they may work and we would love to hear if you try it and you find out "yes it does work" or "no it didn't work" because that IdP didn't adhere to the same standards as the other IdPs. Short term, we may try to get feedback on the most popular other SAML IdPs and possibly test with some of those, but currently we have no time frames or specific plans for doing so. To add on, there are 2 types of IBM TFIM available depending on your business requirements: Full Product of TFIM as well as TFIM Business Gateway.

Q: We had a question in the webchat, if we could elaborate on SAML as it applies to Sametime, Connections, and Traveler. The panel that we invited here today specializes in Domino, so I'm not sure if we will get that answer.

A: We do have our IBM SmartCloud which has support for many of these various components using SAML. So it's on our radar to bring the support that we have in the IBM SmartCloud to the on-premises. It seems like it would be a modest effort to bring, for example, support to set up my premises Sametime. We have Support, as I mentioned, for SAML in the SmartCloud. It would be a small project to bring support to the on-premises Sametime. But it's not yet currently scheduled. The same would be true for Traveler Support, Quickr Support, Connections Support. All the various components we think that it would be a small amount of development effort to make all of these components work in the on-premises side of it because it is already working on the SmartCloud side. We need to assess the demands for these and then schedule the tasks. So far none of those other components do support SAML in the on-premises side.

Q: My question is, does SAML have the name mapping ability that Directory Assistance does for an LDAP connection? Are you able to configure what directory attribute to use as a Notes Name? What name would the user be known as for the duration of any given session? Would it be the Notes Name, or the SMTP email address?

A: The way that you should think about this is, the Domino Directory infrastructure does not need to change at all for SAML. It stays exactly as it always has been. So if you are using Directory Assistance in order to find users in LDAP directories and you are using name mapping to map from an LDAP name to a Domino name, you continue to use that. The key is, when you have the SAML assertion, it contains the user's email address and that user's email address is going to be looked up and it needs to map to one Domino Distinguished name. If that's true you can do that by Domino Person records, or you can do that by Directory Assistance to LDAP. If that's true, the user is going to be authenticated. If there is confusion about who this email address belongs to, we can't find it in the directory, or it seems to have been assigned to two different users , if there is confusion or missing information, then SAML authentication won't work. You can really just think of it as the Domino side stays exactly the same and the SAML IdP just needs to know the user's email address that is going to be found in Domino for that user.
Even if it doesn't find the user Domino will still give you a session-based authentication, or a token, but you'll be known as the email address which then in turn will probably not pass any ACL checks as you are not likely putting the email address in the ACL for the databases. I have seen that behavior using a quick whoami database that does a @username, if it's opened up to -default- access I see that the email address as the user name. Obviously if the database is not opened to -default- access, you won't get access into it.

Q: You're saying that if the email address is consistent in both the Domino Directory and the Active Directory for SAML, once authentication is made the user is going to be known as email address for the rest of the session?

A: If the email address is consistent between the Active Directory and the Domino Directory then we name that they are known as the Domino username, or Notes name. That's what you want to have happen. You want to have it be the case that the email address gets mapped to a Domino name. It comes back to the name on every ACL or associated with the groups that are on the ACL. We don't support putting email addresses into ACLs so if you have an email address you are almost like an unauthenticated user, you're really not going to get access to protected resources in Domino because the email address will not be in the ACLs.

Q: So I would not have to have Notes Names in Active Directory records?

A: You do have to have Notes Names somewhere, that either have to be mapped through Directory Assistance, Directory Assistance to Active Directory, or they need to be in the Domino Directory. So we still use Access Control in Domino that uses Domino names. So you need to get those Domino name mappings from somewhere. They either need to be directly in person records in Domino or you need to use Directory Assistance name mapping mechanism to have user records in an LDAP directory. So none of those naming requirements have changed. The only additional requirement is that the email address that the IdP notes for the user needs to the be same one that is found in the Domino infrastructure.

Q: Previously, it was stated that it's SMTP address, email address is looked up in both directories and then you are known as the Notes name. Now you're saying that I do have to have a Notes name in the Active Directory record in order to be known as the Notes name for the rest of the session?

A: I'm not sure where you are using Active Directory, but if you're just using this through SAML, the IdP needs to authenticate the user, however it's configured to do that, to provide an email address for the user. That's the only thing the IdP has to provide that links up to something in Domino.

Q: Is the SAML authentication supported in the Notes Browser plugin?

A: No, it is a future goal. It has not been scheduled yet.

Q: When the IdP is set up are we just using the default mapping rule for the assertion, and if so, are there additional attributes that can be set to carry across to Domino? Would Domino make them available to utilize in case, as was discussed with the email ID, having that attribute or other attributes from an LDAP system come across that would be made available to the Domino databases for applications to consume?

A: The attribute that we're looking at in the assertion is always the name ID which will be the email address. That's the only current mapping that we allow. That's always the attribute that we expect in the SAML assertion. We are aware of many uses for other kinds of attributes to be added and we would like to support that in the future but currently we don't. As you can see, it would be a very powerful thing to carry all the information about the user that needs to be known inside the SAML assertion rather than needing to do a lot of directory lookups and driving the information. It would be a very powerful thing to carry more information and be able to pass it down to the application. Currently the Domino side is not consuming that information it may be there, but it's not being provided, it's not going to be allowed or passed to applications by a certain interface.

Q: We are moving to a SmartCloud Enterprise Hybrid solution between Domino and SmartCloud and I just wanted to know if there was any tips or practices we should do to set up the SAML on both sides to make it as seamless as possible.

A: I would say that the guiding force behind your deployment needs to be a requirement for SmartCloud. We do have certain hybrid support that's available today for the Notes Client. I'm not sure exactly what types of components you are trying to tie in, but generally what we've discussed today is the mechanism for using an on-premises Domino and setting that up for SAML. It depends on what components you've purchased and using in SmartCloud but generally you would start with the best practices of SmartCloud and go from there.

Q: I would like to know if SAML would work with products such as Connect Desktop plugin and all the plugins on the right hand side panel in the Notes Client plugins, and in what versions?

A: Yes we do have support for using SAML authentication for the Notes Client plugins. The exception would be embedded Sametime and embedded Connections so, as we mentioned, some of the on-premises IBM components are not yet configurable to use SAML, but if you have some other application that could be using SAML, yes you indeed can configure that in the Notes Client plugin. You can configure it administratively at the Domino Server side and have accounts which support SAML connectivity pushed down to the client.

Q: Generic applications are ok, but not for the IBM-specific products such as Sametime and the desktop plugins?

A: For the Connections, yes. We expect that those types of connectivity would be tested and fully supported in future oncoming releases.

Hide details for Webchat Discussion Webchat Discussion
Webchat Discussion

Q: Will SAML allow us to bypass the use of a Notes id if we're using the browser plugin?

A: Notes ID still needed for a number of purposes.

Q: Can we use other IdP's, specifically SHIBBOLETH?

A: Right now we only support those two IdP's. Other IdPs might work, but are not officially supported by Domino. Domino currently only supports SAML with TFIM and ADFS.

Q: Is Notes not considered a "client" for SAML?

A Yes, Notes can use it too, but this talk today is not about Notes Federated Login. We are covering Web Federated Login on this presentation.

Q: Is there an IBM Identity Provider available? Is this one usable by the Domino entitlement?

A: Tivoli TFIM is an IBM product that can be used as an identity provider.

Q: If I have to use SPNEGO to get this single signon on WAS applications, why would I choose SAML for the Domino apps vs SPNEGO?

A: SSO with 3rd party apps works across DNS boundaries. SPNEGO is restricted to the user logged into the AD domain. SAML is not limited that way. Both SPNEGO and SAML WebSSO results in a LTPA token so you can use either mechanism between WAS and Domino if desired. WAS can use SAML also.

Q: Will this work with the browser plugin?

A: The Notes plugin not currently supported. Will be in the future.

Q: I suppose that this will support webmail?

A: SAML authentication can be used on both your web servers and iNotes servers

Q: How does implementing SAML on Domino affect Traveler?

A: Traveler not currently integrated with Domino SAML. Future goal. Since SAML supplants WebSSO LTPA, it is currently incompatible with Traveler, since Traveler sends the authentication header with each HTTP request.

Q: Any issues regarding webmail if the users are configured as Roaming Users?

A: Federated Login is not supported with Roaming Users that store their ID in their personal address books/Contacts database.

Q: If they're in the ID Vault, is it OK then?

A: SAML is integrated with ID Vault. Roaming is integrated with the ID in the ID Vault

Q: Can one have web-created users with SAML, or does one need real users?

A: The user would preferably be a registered user if any type of encrypted mail operations are needed.

Q: Can we use SAML with Sametime? If so, what release of Sametime?

A: On premises Sametime does not yet support SAML. Future goal.

Q: Can a LDAP directory be used to get the users from Active Directory?

A: Once there is a person document that has an internet email address to identify the user you can use SAML authentication. You can use Directory Assistance to Active directory, so that Domino uses the same directory as the SAML IdP

Q: If by any reason an user is not able to be authenticated with the IdP; will the Domino HTTP credentials take place? That is to say, if the user enters AD credentials and the user is not authenticated with the IdP; but, the user has a person doc with HTTP password. Will the browser ask it for Domino Credentials instead or will it show an error?

A: An unauthenticated user cannot access protected resources in Domino.

Q: If we are already setup with DA record to AD to use AD credentials and are in process to start implementing SPNEGO, should we hold off and investigate SAML instead? Is it a better solution? Notes DN stored in AD attribute for each user.

A: The SAML solution is more flexible. With SAML- you rely on the authentication options of your ADFS. If you still are curious of SPNEGO you can configure the Windows Authentication Server to handle the SPNEGO auto login.

Q: Do you have anyone using SAML with Quickr? Quickr is what is also holding up our SPNEGO rollout.

A: Quickr does not yet support SAML, and Quickr is not supported on ND 9.0x.

Q: I assume SSL is recommended?

A: As with any web authentication, SSL encryption is strongly recommended is required with the ADFS IdP. SAML specification recommends SSL when using the HTTPPost binding profile. SSL is also required if using ADFS as your identity provider.

Q: What are the attribute(s) Domino is using from the IpD?

A: Domino is separate from the IdP. It receives an XML assertion with the user's email name

Q: So email address is where the IdP and Domino match up. Is that it? Is that the only one?

A: Yes the IdP and Domino need to agree on the user's email

Q: Email addresses can change (last names) what affect would that have?

A: If the email addresses no longer match up then the user will not be able to access domino resources. Domino needs to be able to lookup the email address in the SAML assertion and find a user with that email address in Domino or via domino directory assistance. The distinguished name (updated email) probably won't have specific ACL access, but will receive default access.

Q: Do you know what the exact attribute name Domino is expecting (internetaddress)?

A: The IdP does the authentication and then when Domino receives the assertion it tries to match the email address to a Domino user.

Q: Right, I am following you there. But I may need to map attributes from AD to Domino. Just need the attribute name from Domino.

A: "Mail" attribute.

Q: So can we setup SAML with iNotes on a mail server, and leave Traveler using LTPA on another server?

A: Traveler would need to use basic authentication.

Q: Why is this capability only available for Domino 9.0 - Is it possible in 8.5 as well?

A: SAML is a new feature to Domino 9.

Q: It sounds like SAML will allow authentication to Domino without a user typing in username / password. If the SAML authentication fails, will a login window allow a user to attempt to log in with username/password?

A: The IdP will display a user/password login at the beginning of the exchange. If that fails, the login prompt will be redisplayed.

Q: I can just leave Traveler configured that way while other Domino servers use SAML, right? Just making sure Traveler won't hold up a SAML implementation.

A: Correct, you only would need to modify the configuration of your iNotes (non Traveler) web servers

Q: So SAML only works with iNotes via the webserver? No way to make it work with the Notes clients?

A: It can work with Notes, it is possible to set up a Federated Login for your Notes Clients, however this presentation is for Web Federated Login.
Notes and Domino Wiki Article for Notes Federated Login:

Q: We have clients who use SiteMinder and we have implemented SiteMinder integration for Domino server. How does SAML change this scenario? Trying to understand how SAML can be placed in SiteMinder installation.

A: SiteMinder does what SAML would do. It takes care of pre-authenticating the user before they get to Domino. Not sure why you would need both.

Q: So even using SAML, a user will still need to enter a username/password pair, but it will authenticate against the IdP instead of Domino. Is my understanding correct?

A: Correct.

Q: After configuring the Domino server, is it possible to login without SAML with the same URL or we need a another domain name to logon to? Ex: Admin account of the Domino Server that is not participated in SAML.

A: If you have SAML authentication setup for your internet site document or your server document it is not possible to have your admin account login with the basic authentication or session authentication on Domino to the same URL

Q: What is limit for time sync from NTP so it will not break ?

A: There are some defaults, I believe they are on the order of 5 minutes. You can specify the duration of the assertion when establishing the IdP partnership. The two timestamps are 'not before' and 'not after'. The assertion is valid between those two times. The case that was mentioned in the presentation was (likely) referring to the 'not before' time, as that is started as the current time. The worst case scenario is that the assertion is generated with a 'not before' timestamp that is later than the current time on the domino server. There is a setting that allows some leniency for that case, but yes...NTP is a good solution for the problem.

Q: just for confirmation... for SAML to work both the IdP and the Domino server must have a reference to the user authenticating?

A: Yes that is correct

Q: If I setup Domino 9 servers for SAML authentication and an LTPA token gets created that is shared with Domino 8/8.5 systems that would work right?

A: Yes that would work. You can even share the LTPAToken with other IBM Webservers (WAS). You can still also have the old Web SSO enabled so that users can move to other servers that are not using SAML authentication

Q: So we need to import all the accounts from SAML to be able to logon and have a Notes Name

A: You will need to have a person document that contains an email address that corresponds to an account in the IdP

Q: Can we use this to get rid of the Notes ID password and just use the AD credentials for everything?

A: Yes, you are removing Domino from the authentication step. The IdP takes over authentication from Domino.

Related Resources

The resources mentioned in the Open Mic have been posted to our support Twitter account at #icsopenmic

You can also find us on Facebook at:

Security Assertion Markup Language (SAML) V2.0 Technical Overview:

SAML Notes Federated Login:



SAML 2.0 Specifications:

ICS Support YouTube video: Implementing Web Federated Login in Domino using SAML:

Original publication date


Document information

More support for: IBM Domino
Single Sign-on (SSO)

Software version: 9.0

Operating system(s): AIX, IBM i, Linux, Solaris, Windows

Reference #: 7039148

Modified date: 14 August 2013

Translate this page: