Federation Guides › Partnership Federation Guide › Single Sign-on Configuration › Single Sign-on to Office 365

Single Sign-on to Office 365

CA SiteMinder® Federation enables single sign-on between enterprise users and Office 365 services. Federating to Office 365 removes the burden of hosting services locally. For example, an enterprise user logs in to the desktop email client but is unaware that the service is in the cloud. The sign-in experience with Office 365 is the same as if they were connected to an on-premise application.

The following profiles are available for single sign-on to Office 365:

WS-Federation Passive Requestor Profile

WS-Federation Passive Requestor Profile works with passive requestors, primarily web browsers, or browser-based applications that support HTTP. The passive profile enables single sign-on between these clients and Microsoft Office 365.

WS-Federation Active Requestor Profile

The Security Token Service (STS) implements the WS-Federation Active Requestor Profile. This profile enables single sign-on between SOAP-enabled desktop clients and the following Office 365 services:

• Exchange Online (Outlook)
• Lync Online
• Dynamics CRM Online

The clients send and receive SOAP messages using HTTP-POST requests and responses. Users can sign in with their enterprise credentials and gain access to Outlook and Lync.

CA SiteMinder® Federation provides the STS service, which serves as an Identity Provider that Office 365 trusts. The STS service issues security tokens that Office 365 services can consume.

To implement single sign-on to Office 365, both WS-Federation profiles require a WS-Federation IP-to-RP partnership that is configured at the federation system.

For the WS-Federation Active Requestor Profile, these other components are also required:

• The STS service that is enabled at the partnership
• STS configured on the CA SiteMinder® Secure Proxy Server (SPS).

The following graphic shows the required configuration steps for web-based client SSO (Passive Requestor Profile):

The following graphic shows the required configuration steps for SOAP-based client SSO (Active Requestor Profile):

Complete the following tasks at the federation system:

1. Verify the prerequisites for SSO to Office 365.
2. Define WS-Federation local IP and remote RP entities.
3. Configure the WS-Federation IP-to-RP partnership.
4. Configure a trust relationship between Office 365 and STS. (SOAP-based SSO only)

Complete the following tasks on CA SiteMinder® SPS for deploying STS (SOAP-based SSO only):

1. Verify the STS setup prerequisites.
2. Configure the JVM to use the JSafeJCE security provider.
3. Deploy STS on CA SiteMinder® SPS.

For supplemental configuration details about single sign-on to Office 365, view the appropriate runbook in the CA SiteMinder® Federation Cloud Runbook Library. You need a login to view this content.

Verify the Prerequisites for SSO to Office 365

For single sign-on to Office 365, be aware of the requirements for:

• Office 365 setup
• CA SiteMinder® user directory

Office 365 Setup Requirements

• Register and obtain an Office 365 domain. The plan that you register for must support single sign-on.
• Register a domain that you own.
• Add your domain to the Office 365 domain.
• Update the DNS record for the Office 365 domain that you own.

For information on configuring your deployment to work with Office 365, refer to the relevant Microsoft documentation for instructions on how to:

• Register and subscribe to Office 365.
• Configure directory synchronization between the on-premise and Office 365 user directory.
• Establish a trust relationship with Office 365 and the on-premise Secure Proxy Server that is configured with STS.

For supplemental configuration details about single sign-on to Office 365, view the appropriate runbook in the CA SiteMinder® Federation Cloud Runbook Library. You need a login to view this content.

CA SiteMinder® User Directory Requirements

• When you configure a user directory connection in the Administrative UI, verify that the ImmutableID and the UPN attributes exist for federation users. The values for these attributes in the on-premise user directory must match what is in the Office 365 directory.

  The Immutable ID and the UPN are required. Supply these values when you configure the WS-Federation partnership.

More information:

Verify the STS Setup Requirements

Configure a WS-Federation Partnership with Office 365

Configure a WS-Federation partnership with Office 365. A WS-Federation IP-to-RP partnership is necessary for either web-based or SOAP-based client SSO.

In this partnership:

• CA SiteMinder® is the Identity Provider (IP)
• Office 365 is the Resource Partner (RP)

The differences between this partnership to configure WS-Federation Passive Requestor Profile and Active Requestor Profile are:

• Enabling STS for the Active Requestor Profile
• Configuring Sign-out, which is optional. Sign-out is only relevant for WS-Federation Passive Requestor Profile.

The following graphic shows a recommended deployment for this federated solution.

Define a Local IP Entity for an Office 365 Partnership

The on-premise federation system is the Identity Provider in the partnership with Office 365. As the Identity Provider, the system issues the security token containing the SAML 1.1 assertion.

Create a local Identity Provider entity with a SAML 1.1 token.

Follow these steps:

1. Log in to the Administrative UI.
2. Select Federation, Partnership Federation, Entities.
3. Click Create Entity.

   The Create Entity dialog displays.

4. Select Local to indicate that you are creating an entity that is local to your site.
5. Configure the remaining fields:

   New Entity Type

   Select WSFED Identity Provider.

   SAML Token Type

   SAML 1.1

6. Click Next to configure specifics about the entity.

   In the Configure Entity step, complete all required fields in the dialog. Pay particular attention to the following fields:

   Note: Click Help for a description of fields, controls, and their respective requirements.

   Entity ID

   Enter the IssuerURI specified in the Office 365 domain.

   For this local partner, the Entity ID does not have to be unique.

   Entity Name

   Enter any name that identifies this local IP. The Entity Name identifies an entity object in the policy store and it must be a unique value. This value is for internal use only; the remote partner is not aware of this value.

   Base URL

   Specify the URL for the system. For communication with Office 365, this URL must be over an SSL connection. For example, https://fedserver.example.com.

   Disambiguation ID (required for Office 365)

   Set this ID only when there are multiple partnerships between the same IP and RP, and your company has separate business units with their own relationship with Office 365. Office 365 uses a single ID to identify itself as an RP. CA SiteMinder® Federation does not allow multiple partnerships with the same IP or RP ID. A disambiguation ID enables the system to differentiate partnerships with a unique logical path suffix for the service URLs given to a specific partner. Only one federation service exists, but the suffix that is combined with the RP ID creates a unique partnership lookup key.

   Example: microsoftonline

   The Disambiguation ID is appended to federation service URLs so requests go to the correct remote partner.

   Example:

   Passive Requestor Service URL: https://fedserver1.forwardinc.com/affwebservices/public/
   wsfeddispatcher/microsoftonline

   "microsoftonline" is the disambiguation ID.

   Enter an alphanumeric string but do not use any special characters.

   Sign-Out Confirm URL

   Specifies the URL at the Identity Provider that performs sign-out.

   Default: http://ip_server:port/affwebservices/signoutconfirmurl.jsp

   ip_server:port

   Specifies the server and port number of the Identity Provider system. The system is hosting the Web Agent Option Pack or the SPS federation gateway, depending on which component is installed in your federation network.

   Signing Private Key Alias

   For signing and encryption features, import the appropriate key and certificate pairs in the certificate data store.

   Important! The public certificate that is associated with this private key must be imported into the Office 365 federation domain.

   Supported Name ID Formats and Attributes

   Unspecified

   UPN Attribute

   The UPN is the user principal name.

   Assertion Attribute

   UPN

   Namespace

   http://schemas.xmlsoap.org/claims

   Note: Microsoft provides this value. Enter the name space value as it is shown. Office 365 requires this exact value.

   Immutable ID Attribute

   The ImmutableID is a unique attribute that distinguishes the user in the on-premise Microsoft directory.

   Assertion Attribute

   ImmutableID

   Namespace

   http://schemas.microsoft.com/LIVEID/Federation/2008/05

   Note: Microsoft provides this value. Enter the name space value as it is shown. Office 365 requires this exact value.

7. Click Confirm when all the required fields are complete.
8. Configure the remote entity.

Define a Remote RP Entity for an Office 365 Partnership

Create a remote Resource Partner that represents Office 365. To define the entity, import metadata, if it is available, or configure the entity using the following procedure.

Follow these steps:

1. Log in to the Administrative UI.
2. Select Federation, Partnership Federation, Entities.
3. Click Create Entity.

   The Create Entity dialog displays.

   Note: Click Help for a description of fields, controls, and their respective requirements.

4. Select Remote to indicate that you are creating an entity that is remote to your location.
5. Configure the remaining fields:

   New Entity Type

   Select WSFED Resource Partner.

   SAML Token Type

   SAML 1.1

6. Click Next to configure specifics about the entity.
7. In the Configure Entity step, complete the following required fields:

   Note: Click Help for a description of fields, controls, and their respective requirements.

   Entity ID

   urn.federation:MicrosoftOnline.

   Entity Name

   Enter any name that identifies the RP.

   Remote Security Token Consumer Service URL

   Specify the URL for Office 365 security token service. Obtain this URL from Microsoft. This URL must be over an SSL connection. For example, https://login.microsoftonline.com.

   Remote Signout URL (Passive Requestor Profile only)

   Specify the URL for Office 365 sign-out service. Obtain this URL from Microsoft. This URL must be over an SSL connection. For example, https://login.microsoftonline.com.

   Note: For Office 365, the URLs for the security token consumer service and the signout URL are the same.

   Supported Name ID Formats

   Unspecified

8. Click Confirm after reviewing the configuration.

Configure a WS-Federation Partnership with Office 365

After you create the local IP and remote RP entities, configure a WS-Federation partnership. Steps that are specific to one or the other WS-Federation profile is noted.

Follow these steps:

1. Log on to the Administrative UI.
2. Navigate to Federation, Partnership Federation, Partnerships.
3. From the Create Partnership pull-down menu, select WSFED IP->RP.

   A dialog opens with the partnership wizard displayed at the top.

4. In step 1 of the partnership wizard, complete the required fields for a standard federated configuration.
   1. For Active Requestor Profile only, select the STS for WSFED Active Profile check box.
5. Optionally, select Enable Metadata Exchange to create a federation metadata document that reflects the active profile endpoints and data. The URL for this document is:

   https://sps_host/affwebservices/public/FederationMetadata/partnership_name

   Note: sps_host is the Secure Proxy Server with STS configured.

   The metadata document provides details about the partnership, such as WS-Federation passive and active profile end points and data.

6. In step 2 of the partnership wizard, select federation users for this partnership.
7. In step 3 of the partnership wizard, enter the required settings for the Name ID:

   NameID Format

   Unspecified

   Name ID Type

   User Attribute

   Name ID Value

   Immutable ID assigned by Office 365

8. Remain at step 3 of the wizard and complete the Assertion Attribute settings:
   1. Confirm that the UPN and ImmutableID assertion attributes are inherited from the local IP entity. If you did not add these attributes at the entity level, specify them here.
   2. Set the Type field to User Attribute for both attributes.
   3. Set the Value field to the user directory attribute that has the UPN and ImmutableID value respectively.
9. In step 4 of the partnership wizard, complete the following fields in the Authentication section:

   Authentication Mode

   Local

   Authentication URL

   If the WS-Federation Passive Requestor Profile is in use, complete this field. Ignore this field for the Active Requestor Profile.

   https://CA SiteMinder®_system/siteminderagent/redirectjsp/redirect.jsp

10. Remain at step 4 of the wizard and complete the following fields in the SSO section and the SLO section:

    Audience

    urn:federation:MicrosoftOnline

    Security Token Consumer Service URL

    https://login.microsoftonline.com/

    Complete the Signout fields only for the WS-Federation Passive Requestor Profile. They are not relevant for the Active Requestor Profile.

    Signout Confirm URL (optional)

    Enter the URL for your deployment, assuming sign-out is configured.

    Signout URL (optional)

    https://login.microsoftonline.com/

11. Accept the defaults for the remaining settings, then advance to the next step.
12. In step 5 of the partnership wizard, enable the signature processing and select the alias for the proper private key/certificate pair.
13. Move to the Confirm step. Review the configuration and click Finish to save the partnership.

    You return to the Partnership List.

14. Select Action, Activate to activate the partnership.

STS is defined for your federated partnership. Now configure the STS component on the CA SiteMinder® SPS.

Configure a Trust Relationship between Office 365 and STS (SOAP-based SSO)

To enable SSO between SOAP-based clients and Office 365, configure a trust relationship between the Office 365 Sign-In Service and the on-premise server with STS. Set up this relationship after you purchase an Office 365 subscription and after you configure directory synchronization.

Configure the trust relationship using the Windows Powershell commands. The command that initially configures the trust relationship is Set-MsolDomainFederationSettings. Run this command at your enterprise. For the correct procedure, see the Microsoft documentation on Windows Powershell.

This command can take command arguments such as:

• Domain
• ActiveLogOnUri (the ws-username endpoint of the on-premises STS)
• PassiveLogOnUri
• IssuerUri
• MetadataExchangeUri
• SigningCertficate

These command arguments are enough to establish a trust relationship from the Office 365 to the on-premises Secure Proxy Server system with STS.

To determine the STS endpoints for the command arguments, view an existing WS-Federation partnership in the CA SiteMinder® Administrative UI. These endpoints are based on the values in the WS-Federation IP-to-RP partnership. Use these end points when configuring Office 365 to trust the Secure Proxy Server system with STS.

Note: To see the configuration of a specific WS-Federation partnership, select Action, View next to that partnership.

Configure CA SiteMinder® SPS

For CA SiteMinder® to implement single sign-on using the WS-Federation Active Profile, an STS web service is needed. To manage requests from Office 365, deploy STS on CA SiteMinder® SPS.

Note: The STS web service must be hosted on CA SiteMinder® SPS at your enterprise. The service cannot be hosted on a different CA SiteMinder® platform.

When a client application tries to connect to Office 365, Office 365 issues a token request to STS. STS issues a security token with a SAML 1.1 assertion that Office 365 can consume. The client application is able to access Office 365.

The following graphic shows a recommended deployment for this federated solution. Many ways to route traffic to the STS are available.

Follow these steps:

1. Verify the STS setup requirements.
2. Configure the JVM to use the JSafeJCE security provider.
3. Deploy STS.