SAML federated identity concepts

Overview of the process using SAML

Cloud services rely on SAML to provide the SSO services. In this implementation, your organization is the identity provider, and the cloud service is the service provider. You can use either SAML 1.1 or SAML 2.0.

As the identity provider, your organization authenticates users. The authentication can be by a login with a user name and password, or by some other method. For mobile apps, the authentication must be by a login with user name and password.

When a user gains access to your intranet and attempts to use a cloud service, a SAML assertion is sent from your organization to the SAML endpoint in the cloud service. The SAML assertion securely identifies the user. The cloud service uses the SAML assertion to decide whether the user can access it.

Flow models

Two flow models exist in federated identity management. One model is the identity provider initiated model (IdP-initiated), and the other is the service provider initiated model (SP-initiated). Mobile apps use the SP-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, the cloud services use 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 cloud services, and is not implemented.

The cloud services implement 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:

IdP-initiated

1. The user gains access to your intranet via your organization's authentication mechanism.
2. The user navigates to a web page on your intranet that contains a link to a cloud product such as Connections Cloud or SmartCloud Notes® web.
3. The user clicks the link.
4. The SSO process is initiated. A SAML assertion is sent to the cloud endpoint via HTTP POST. If the user has a valid account, access is granted.
5. The user interacts with the cloud product.

SP-initiated hybrid

1. The user navigates to the cloud service login page.
2. The user clicks Use My Organization's Login.
3. The user enters the email address that is associated with the user’s account.
4. The cloud service looks up the email address and then redirects the user to your organization’s authentication mechanism.
5. The flow continues from Step 4 of the IdP-initiated model.

The SP-initiated hybrid flow model also applies to mobile apps. Before using a mobile app, the user must do a one-time setup of the mobile app to use a cloud server. The setup process is different for each mobile app; instructions are included in the documentation of each app.

The following outline describes the flow for mobile apps:

SP-initiated hybrid for mobile apps

1. A mobile app initiates a connection to a cloud service.
2. The cloud server looks up the email address and then responds with the mobile login URL of your organization’s mobile authentication mechanism.
3. The mobile client issues a basic authentication request to the mobile login URL with the user's email address and password.
4. If the basic authentication is successful, a SAML assertion is returned to the mobile app.
5. The mobile app sends the SAML assertion to the cloud endpoint via HTTP POST. If the user has a valid account, access is granted.
6. The mobile user interacts with the cloud product.

Login types

Four types of login are available: Standard, Federated, UserChoice, and AdminChoice. By default, all users in your organization are assigned the Standard type unless you enable one of the other types.

Standard (non-federated)

Cloud login is independent of, and separate from, your organization's login procedure. Users must log in with their email address and password to use the cloud-based services.

The Standard type is the default type, and is the simplest and easiest type to use because it requires no action on your part.

Federated

All users must authenticate with your organization before they can access the cloud-based services. Users do not have a cloud user name or password. If they go to the cloud login page, they must click Use My Organization's Login. The Federated type applies to all users in your organization.

The Federated type is convenient for your users who normally work from the office. They can log on to your system and use cloud products without needing a separate username/password combination. However, if any of your users work from home or work while traveling, your directory servers must be accessible from the Internet. Also, because your users do not have a separate login for the cloud, services that do not support SAML or the use of application passwords, such as POP/IMAP, will not be available.

If you choose the Federated type, you must implement the SP-initiated flow model.

UserChoice

Users have the option of authenticating with your organization before accessing the cloud-based services, or using their cloud user name and password to log on to the cloud. The UserChoice type applies to all users in your organization.

The UserChoice type allows your users to access the cloud from the Internet, but you do not need to make your directory servers accessible from the Internet. Your users can use the single sign-on services when they are in the office, and the cloud login when they are outside the office.

AdminChoice

Each user in your organization is assigned one of the previously listed types: Standard, Federated, or UserChoice. If you do not specify a type for a particular user, the user is assigned the Standard type.

Use the AdminChoice type if you have one group of users who normally work in the office, and another group of users who normally work from home or who travel frequently. For example, the office workers can be assigned the Federated type, and the traveling sales team can be assigned the UserChoice type.

You can also use the AdminChoice type to group users by the services that are available to them. Users with the Federated type do not have access to POP/IMAP, but users of the UserChoice type do have access to POP/IMAP.

If you choose the AdminChoice type, you must implement the SP-initiated flow model.

After one of the federation types is implemented, you can change to one of the other types by contacting your customer services representative. The customer services representative will advise you on the process. If you are using the Partial type, you can change individual users from one type to another without the need to contact your customer services representative.

You have the option of specifying a URL that the browser gets redirected to when the user logs out of a single sign-on session. This allows you to have a custom web page that users see when they log out. You can also use the URL to clear the user's session with your identity provider. Your customer services representative can provide more information about this feature and how to use it.