This section describes the option of integrating an on-premises federated identity management solution with IBM Connections Cloud. As shown in the following figure, this option is about integrating an on-premises directory system through SingleSignOn (SSO) using the Security Access Markup Language (SAML) with IBM Connections Cloud.
What is a federated identity?
A federated identity is a general term that encompasses details regarding how two or more organizations want to share identity information. A federated identity implementation usually consists of a single system, the identity provider (IdP), that authenticates a user and then vouches for the user’s identity to other systems which do not have access to the user’s authentication credentials.
The federated identity is based on a trust relationship between an identity provider and a service provider. The identity provider owns the user identities, controls the authentication of these identities, and provides identity information. This normally is a directory server on the client’s premises, such as Tivoli or Active Directory. The service provider controls access to services, trusts asserted identity information provided by the identity provider, and provides access based on the asserted identity. This is IBM Connections Cloud.
The most common use of federated identity is Multi-Domain Single Sign On (MDSSO), or more simply, SSO. In the general case, as a user moves from one domain (web site) to another, the source site provides a token to assert that the user is valid, and the destination site, based on the existence of a previously defined trust relationship with the source, accepts this assertion (after its genuineness is verified) and allows the user access.
Consider what is normally used to log in to IBM Connections Cloud, your email address and password. Those credentials might be different from your existing systems. Having users now use an email address and password could be a problem for those that have been trained to use their ID/PIN combination. To address this concern, SAML can be used as the intermediary. SAML also provides the ability to specify where the user should go inside IBM Connections Cloud after login. In the following diagram, you can see that the user authenticates to the company identity provider, then obtains access through the SAML assertion to the user dashboard, and finally to the services itself, all from the same web browser session.
So, in short, federated identity allows users who are logged on to your company’s system to use the cloud-based services without having to log on again.
One of the advantages of the federated identity, is that after a system is certain that a user is who he claims to be, the service provider can, in turn, become an identity provider to other service providers. This allows IIBM Connections Cloud, for example, to provide an assertion of identity that allows users to access the component services within IBM Connections Cloud regardless of where a service is physically located, or whether it or not it can share the IBM Connections Cloud domain or, like with the email services, operates using the client’s domain. Any current or future service (including third party services) that might be offered as part of IBM Connections Cloud can be linked in this manner, allowing users to move between them seamlessly. It does not matter which service the user starts his session with, or how he might move around between services, as long as the first authentication came from the user’s primary identity provider – his or her company.
Who initiates the process?
Two flow models exist in federated identity management:
- IdP-initiated: This is the identity provider initiated model.
- SP-initiated: This is the service provider initiated model.
Normally, the SP-initiated flow model is not available in SAML 1.1 because SAML 1.1 does not support Identity Provider Discovery Profile. However, IBM Connections Cloud uses a hybrid version of SP-initiated that allows both SAML 1.1 and SAML 2.0. As a result, Identity Provider Discovery Profile is not required by IBM Connections Cloud, and is not implemented.
IBM Connections Cloud implements the Browser/POST profile that is used in SAML 1.1 and is compatible with the Web Browser SSO profile in SAML 2.0. Other profiles are not supported at this time.
The following outlines describe the two flows:
- The user gains access to your intranet through your organization's authentication mechanism.
- The user navigates to a web page on your intranet that contains a link to a IBM Connections Cloud product such as Engage or IBM Connections.
- The user clicks the link.
- The SSO process is initiated. A SAML assertion is sent to the IBM Connections Cloud endpoint through HTTP POST. If the user has a valid account, access is granted.
- The user interacts with IBM Connections Cloud.
- The user navigates to the IBM Connections Cloud login page.
- The user clicks Use My Organization's Login.
- The user enters the email address that is associated with the user’s account.
- IBM Connections Cloud looks up the email address and then redirects the user to your organization’s authentication mechanism.
- The SSO process is initiated. A SAML assertion is sent to the IBM Connections Cloud endpoint using HTTP POST. If the user has a valid account, access is granted.
- The user interacts with IBM Connections Cloud.
The two step (SP-initiated hybrid) SSO process from a user perspective is shown here:
What is SAML?
The Security Assertion Markup Language (SAML) standard defines a framework for exchanging security information between online business partners. It was developed by the Security Services Technical Committee (SSTC) of the standards organization OASIS (the Organization for the Advancement of Structured Information Standards). This document provides a technical description of SAML V2.0.
There are a number of competing approaches to federated identity, including both proprietary and open standards. Clearly proprietary standards are inappropriate for SaaS offerings, and amongst the various alternatives SAML is widely considered the leading choice. In 2007, Gartner, an industry analyst firm, declared SAML 2.0 “the de facto federation standard across industries.” The federated identity services embedded within IBM Connections Cloud are provided by the Tivoli Federated Identity Manager (TFIM) which has the capability to accept identity tokens in a number of formats, including SAML 2.0, OpenID, and WS-Federation. Thus, a choice existed. SAML 1.1 was chosen over the others due to a combination of factors including its wide spread availability, security concerns raised about some of the alternatives, and ease of implementation for our clients. A federated identity using SAML is supported by a wide range of commonly used directory servers, including:
- IBM TFIM and IBM TFIM Business Gateway
- Microsoft®Active Directory Federation Services
- Sun Federated Access Manager (formerly Sun Access Manager and Sun Federation Manager)
- Computer Associates Siteminder®
- And others based on OpenSAML
The identity provider can be set up on premises but also in the IBM Softlayer cloud as a dedicated customer solution, making a total cloud solution closer than ever before.
Because the identity provider is fully customizable by your organization, there are many options to use in the authentication process. For example, but not limited to:
- On premises user names and passwords
- RSA Tokens
- Iris Scans
Identity federation types
SAML does not solve everything, notably in the context of email. The established protocols for POP, IMAP, and SMTP do not support federated identity concepts well. To help overcome these limitations of these older, established, mail protocols, CSG is able to adjust your IBM Connections Cloud environment to offer several federation configuration options:
- Non-Federated: An organization in which all subscribers will authenticate with a user name and password stored in the IBM Connections Cloud. In this case SAML SSO is not being used.
- Federated: An organization in which all subscribers must authenticate with their organization’s identity provider. Users cannot change their password inside IBM Connections Cloud. In this case SAML SSO is being used.
- Partial-Federated: An organization can have subscribers that are non-federated, federated, or modified-federated. In this case SAML SSO is being used, but if and how it is to be used is set individually for each user.
- Modified-Federated: An organization that will allow all subscribers to authenticate with a username and password stored in IBM Connections Cloud or their organization’s identity provider. In this case SAML SSO is being used, but is optional.
The difference between Modified and Partial is that in a Modified organization all users have the option to use either authentication mechanism at any time. For example, a user clicking through from the company Intranet may be automatically signed on using SAML, but going directly to www.collabserv.com from home will be allowed to log in with their user ID and password. Organizations defined as Partial have users who carry one of the explicit designations below, which controls the authentication process for the individual user.
There are three user types:
- Non-Federated: These are subscribers that use a username and password to authenticate directly with the IBM Connections Cloud. These users cannot use single sign on.
- Federated: These are subscribers that will not have a password in the IBM Connections Cloud and must authenticate through their organization’s identity provider. For these users SAML single sign on is mandatory.
- Modified: Subscribers of this type will be able to authenticate both with passwords stored in the IBM Connections Cloud or by using their organizations Identity Provider using SAML single sign on.
The Federation type for the organization should be specified at the time the service is initially configured, as it will impact the process of user on-boarding (for example, federated users will not be asked to supply an initial password), although it can be changed later.
What you should be aware of
Implementing SSO with the IBM Connections Cloud has a couple of items you should be aware off. Some technologies are not currently possible, others are when you follow a certain direction:
- With ID Vault & Active Directory, using Notes Shared Login (NSL, Domino Policy deployment based solution). Not Client Single Login (CSL) which is seen in the IBM Notes Client as a separate install option.
- With IBM SmartCloud Notes integrated IBM Sametime chat enabled to manage the client configuration.
- With IBM Notes 9 and accounts policies configured against forms-based on-premises SAML Identity Provider.
- With latest IBM Sametime client configured against forms-based on-premises SAML Identity Provider. For more information look at the Configuring the Sametime rich client for SAML and downloading information source.
- With custom developed authentication module specific to forms-based on-premises SAML Identity Provider.
- Common SAML implementation planned for a future release of mobile applications.
Preparing for federated identity management
The difficulty of getting your system ready for federated identity management depends on both the state of your system, and on your knowledge and experience with SAML, SSO, LDAP, and related technologies.
Before contacting your IBM customer service representative to enable federated identity management, review the following checklist (the mentioned topics are to be found in the IBM Knowledge Center under configuring logins > setting up federated identity management
- Choose the version of SAML that you want to use. You can use either SAML 1.1 or SAML 2.0.
- Choose the type of federation that you want to employ: Federated, UserChoice, or AdminChoice. See the topic SAML federated identity concepts for more information.
- Review the IdP-initiated flow model and the SP-initiated hybrid flow model that Connections Cloud supports. See the topic SAML federated identity concepts for more information.
- Implement SAML on your web server. You can use Tivoli® Federated Identity Manger, OpenSAML, Active Directory Federation, or some other federated identity manager.
- If you are setting up federated identity for users of mobile apps, create a second endpoint that accepts basic authorization. The mobile apps work with the SP-initiated flow model only.
- Retrieve or create the private/public key pair that will be used in digital signatures.
- Integrate your directory server with your SAML service. Administration is easier if all of your users are on the same directory server.
- Implement and test the SAML Browser/POST profile in either SAML 1.1 or SAML 2.0.
- Create a dummy service provider and conduct an IdP-initiated single sign-on test to make sure that everything is working correctly.
- Create a SAML metadata file to transmit your identity provider metadata to the IBM customer service representative. If you are using SAML 1.1, you have the option of transmitting most of the information in an email or by some other means that you negotiate with the IBM customer service representative. However, in this case you must transmit the public key inside a Java keystore.
Enabling federated identity management
When your system is ready for testing with IBM Connections Cloud system, contact an IBM customer services representative.
Before you begin
Before you start the enablement process, review the following list:
- Implement and test a federated identity management system that uses SAML. Make sure that your system is configured to send the user’s email address as the subject in a SAML assertion.
- Test your system to make sure that it is configured for the type and flow model that you have chosen. See the topics Federated identity management types and see the Flow models section of SAML federated identity concepts for more information.
- Complete the checklist in the topic: Preparing for federated identity management
To enable federated identity management, send an email to CSG. In the email, request to have federated identity management enabled for your organization. If you already know what version of SAML you are going to use, please let CSG know in this email already. In addition, CSG needs an email address (test email) that IBM can use when IBM sets up the Proof of Concept (PoC/Test) and you need to be ready to submit the metadata that will be used for PoC. An IBM customer services representative will contact you with instructions and provide details of the process.
For more information please review this IBM technote.
Project steps and readiness checklist
Here is a brief outline of the steps and items needed, to get Federated Identity set up. Any of these steps might have to be expanded, in your environment, into a small project to prepare the system. A readiness assessment should be done in advance of planning an implementation of federated identity, following this list.
- Are you currently using a directory server, such as TAM or AD, and is your directory server ready to support SAML based Federated Identity?
- Are your users all using the (or a) directory server? While it is not necessary for all users to be on a consolidated directory, If users are widely distributed over many servers (or some users are not on any) then it will be worth investigating the impact of directory consolidation before trying to set up Federated Identity.
- If you are using multiple directory servers, are any in remote locations that will have slow or unreliable connections to where remote users of IBM Connections Cloud might be logging in from? If access to a directory in Peru is unreliable from New York, this is not necessarily a problem if the server will be reliably available to employees in Peru. On the other hand, if a server in New York is hard to reach for mobile employees who are on assignment in Peru, it may be preferable not to federate those users. This step can help you determine what federation type you will need to set up.
- Are there any reasons (for example, security, network configuration) that would prevent your directory server from being reached from outside the firewall, to provide the necessary service? If security concerns will prevent your primary directory from being reachable for all the necessary cases, consider mirroring only the necessary data set onto another directory server that can be placed in a position with the necessary access available.
- Does the directory server hardware (and network) have capacity to accept the additional workload?
- As the Identity Provider, your set up should be complete, and tested, before providing your trust relationship data to IBM. An end to end test can be performed by setting up a dummy service provider on spare hardware either using your existing software (that is, the same directory server) or by downloading and setting up a free implementation from a source such as OpenSAML.
- Purchase the necessary certificates. Although self-signed certificates can be used, and are good for testing, browsers react badly to them and can confuse users with dire sounding warnings, and repeated requests to trust the certificate.
- Add IBM Connections Cloud as an allowed service for SAML authorization.
- Supply the trust relationship information package to IBM.