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:

   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:

   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://web_agent_optionpack_system/affwebservices/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.

Verify the STS Setup Requirements

Before you deploy STS on CA SiteMinder® SPS, complete the following requirements:

• Install and configure CA SiteMinder® SPS.

  Note: Two or more secure proxy server systems behind a load balancer are recommended, but it is not required.

• Obtain the partnership name from the administrator of the CA SiteMinder® Federation system. Specify this name in the STS Context setting when you deploy STS.
• Enable SSL on CA SiteMinder® SPS.
• Verify that traffic originating from Office 365 can reach the on-premise CA SiteMinder® SPS with STS.
• The secure proxy server system with STS must be reachable by internal traffic and by external traffic from outside the enterprise firewall. Forwarding external traffic can require that you install a proxy in the DMZ. Configure the proxy so it can forward traffic from outside the firewall to the STS.

Configure the JVM to Use the JSafeJCE Security Provider

To enable encryption, configure the JVM that is running the CA SiteMinder® SPS so it uses the JSafeJCE Security Provider.

Follow these steps:

1. Download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files package for the Java version you are using from the Oracle website.
2. Navigate to the following location:

   Windows

   JVM_HOME\lib\security
   

   UNIX

   JVM_HOME/lib/security
   

   JVM_HOME

   Defines the location where Java Runtime Environment (JRE) is installed in JDK of your installation.

3. Patch the following files with the files from the JCE Unlimited Strength Jurisdiction Policy Files package:
   • local_policy.jar
   • US_export_policy.jar
4. Open the java.security file.
5. Add the following line in the List of Providers section JSafeJCE is added as the second security provider:

   security.provider.2=com.rsa.jsafe.provider.JsafeJCE
   

6. Increment the order of preference of the other security providers by 1.
7. Add the following line at the end of the existing security providers list. This line sets the initial FIPS mode of JSafeJCE:

   com.rsa.cryptoj.fips140initialmode=NON_FIPS140_MODE
   

8. Save the changes.

The following example shows the List of Providers section of the java.security file after you configure the JVM:

security.provider.1=sun.security.provider.Sun
security.provider.2=com.rsa.jsafe.provider.JsafeJCE
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
security.provider.10=sun.security.mscapi.SunMSCAPI
com.rsa.cryptoj.fips140initialmode=NON_FIPS140_MODE

Deploy STS

To support the WS-Federation Active Requester Profile, deploy STS on CA SiteMinder® SPS.

Follow these steps:

1. Open the SPS Administrative UI.
2. Navigate to Web Services, Security Token Service.
3. Click Add.
4. Complete the following fields:

   STS Name

   Defines the name of the STS web service. Enter the partnership name that is defined in the Administrative UI.

   STS Context

   Defines the STS context path. Specify the name of the WS-Federation partnership that is defined in the Administrative UI. Enter the value using the syntax /partnership_name.

   Example: /Office365Cloud

5. Click OK and click Save.
6. Restart the system.
7. Test single sign-on to Office 365.

Test and Troubleshoot SSO to Office 365 (Active Requestor Profile)

Test SSO

Verify the WS-Federation configuration and the STS deployment by signing in to Lync or Outlook.

Follow these steps:

1. Log in to Lync or Outlook on the system in your enterprise.
2. Confirm that you get logged in and that you can use the application as if it were installed locally.

Troubleshooting SSO Issues

For WS-Federation partnerships and connectivity issues, use the following methods of investigation:

• Use the WS-Fed Passive Requester profile and verify single sign-on with Microsoft online.

  From a web browser, go to http://portal.microsoftonline.com or Microsoft exchange online. Try logging in with enterprise credentials. If you can successfully log in from the browser but not from the enterprise client, check the setup of the on-premise STS.

• Review what Office 365 knows about CA SiteMinder® as a federation partner and what it knows about federation users. To examine the state of partnerships and users, run the following Microsoft Powershell commands:

  Get-MsolDomainFederationSettings

  Shows the information Microsoft has about your domain, that is, your enterprise. Review the settings and confirm whether they are accurate. Incorrect information can be a cause of federated communications problems.

  Get-MsolUser

  Shows the information Microsoft has about a particular user. Review the user settings and confirm whether they are accurate. Incorrect information can be a cause of federated communications problems.

• Validate the connectivity between your enterprise and Microsoft using Microsoft Remote Connectivity Analyzer. This tool lets you identify connectivity problems with Outlook, Lync, and Office 365. Locate this tool at https://www.testexchangeconnectivity.com/.

For any problems with the STS component, use the following logs and files:

• Review STS logs to verify that STS is operating, and whether there are authentication failures. Check the logs at secure-proxy_install_dir/proxy-engine/logs/partnership_name.log.

  Look for a message that says the STS initialization is complete. This message indicates that STS is running.

• Configure the log settings in the agent-log4j.xml configuration file. Set the log level for all categories to DEBUG so the system records the most detailed information in the partnership_name.log. The agent-log4j.xml file resides in the following directory:

  secure-proxy_install_dir/proxy-engine/conf/sts-config/partnership_name/config/

  Also, set the Checkpoint logger setting, <category name="com.ca.CheckPointLogger," to a priority value of "INFO." This setting writes checkpoint log messages for authentication activities and assertion generation. Checkpoint log messages are descriptive messages with codes that reflect the operation of the STS component.

  The section Federation Trace Logging describes checkpoint messages.

• Examine the WSDL file and confirm that the on-premise STS is responsive. Open a browser and go to http://sts.company.com/partnership_name?wsdl. The string sts.company.com is a place holder for the STS URL. You can find the STS URL in the WS-Federation partnership that is configured in the Administrative UI.