We have tested and support (to a limited extent) SAML with ADFS (2.0 and above I think?) and TFIM. Currently we DO NOT support any other IdP's. If this is a Connections on Cloud opportunity then there MIGHT be a possability to support different IdPs, but this will need to be raised with your IBM sales rep first and the Connections on Cloud team will need to be involved early to make a call on wether or not they'll support whatever configuration you're looking at.
For on-premesis stuff, the process for Domino may be different, but to get SAML support for Connections you MUST open a PMR first, fill out a questionaire showing your IdP configuration, network architecture and application configuration then wait for L3 support to approve your request.
That said, I've seen customers setup SAML for Domino and Connections with at least two other IdP's (PortalGuard w/ Domino and SimpleSAMLphp w/ Connections, Domino and Docs). Both of those IdP's needed some tweaking to work properly - in both cases the redirection/return-URL parameter name (named "loginToRP" for ADFS and "partnerid" for TFIM) needed to be either re-written to something supported by the IdP or the IdP needed to be configured to process it properly. In a different case the assertion itself (being generated by the IdP) was not exactly to the SAML spec - although it worked with at least two other companies' SAML-consuming services. I'd like to stress IBM does not officially support these configurations, but the customers involved are chosing to take the risks involved with running an unsupported configuration.
You should know in advance that Domino/Connections/Portal etc. are very strict on validating the signatures and XML payloads of SAML assertions - everything in the SAML specification must be implemented properly by the IdP and all attributes must be properly declared. Something as simple as a default attribute not being provided or a single character being uppercase when it should be lowercase can prevent the whole thing working and is very painful to debug taking many hours of support's time.
Finally, below is an excerpt from an internal e-mail sent to the IBM pre-sales team recently. Although many customers have SAML configured and working without issues, I think it sheds some light on IBM's concerns around partners and customers attempting to configure SAML, especially when they aren't already experienced in doing so:
I'd like to very much second what <NAME REMOVED> has said here.
I've been drafted in to work on no fewer than five SAML engagements (one of which being a critsit) in the past few months. All of them have demonstrated a fundamental lack of honesty/modesty and/or care and attention to detail when it came to the understanding and implementation of some, much or all of parts of a SAML architecture those technologists needing help were involved with.
SAML sounds like a panacea for single-sign-on to customers (and for partners pressured to implement a solution). They seldom realise the real cost and sheer attention to detail required to set it up properly. In a number of cases I've seen the security model destroyed by it being set-up it up in an incompetent fashion and - literally - weeks of man effort wasted due to a lack of skills, experience, theoretical knowledge and hubris.
The ICS team (both in the labs and wider IBM) are in many cases out of our element when it comes to anything to do with SAML beyond our products implementation [and supported configurations] of it. This means we must involve IBM Security Solutions people to assist on non-revenue generating work - [nearly always] with customers not using IBM products to provide the SAML back-ends for our technology.
Below is a very much [non-exhaustive] list of common issues which tend to crop-up, all of which can take significant time to identify and solve; most of which are things the labs cannot effectively help on through a PMR process and must be pre-empted with customers setting up SAML [competently and correctly] beforehand:
-
A single attribute or element missing from the XML payload of a SAML assertion.
-
A certificate which uses SHA-1 HMACs or other insecure or deprecated algorithms (I've even seen *sigh* MD5!)
-
Certificates which use DSA or ECDSA keys where only RSA are supported by some parts of the architecture.
-
Servers where times are out of sync due to not running ntpd or equivalent.
-
Time-based validity windows that are too large and are refused by some parts of the architecture (in one case I've seen assertions set to be valid for *sigh again* MONTHS, not hours.)
-
Invalid trust assertions in the payload (for services that don't exist, for accounts that cannot be identified, for non-user principals ... )
-
Untrusted signatures being used to sign the payload (forgotten to import certs, importing the wrong certs, typo's in hostnames, issuers which don't exist...)
SAML is a great technology, but it is also a system designed to be secure whilst tying together many different systems. Doing this right matters (else why bother at all with authentication and authorisation), doing it right also requires detailed knowledge of the systems involved, the theory of SAML and a healthy respect for knowing no matter how skilled an administrator you are, you won't get this done in a day and will need to "dot every i and cross every t" before it works.
We do have some [great] SAML skills in ICS - <NAME REMOVED> in the US being the primary lead from the Domino side of things [and <NAMES REMOVED> in the Dublin labs]. The Connections on Cloud team now also have a been through a good many trials by fire setting it up with customers using federated identity in our SaaS offerings.
[Remember there are other options for SSO (SPNEGO, Kerberos, SSO via LTPA, WebSEAL, SiteMinder etc.) which may be easier to setup and maintain for customers. SAML is just another option, and one which requires more than a modicum of care.]
Edit: typos.