Broadcom/CA Technologies Single Sign-On (SSO) to Use SAML Federation to Microsoft Office 365

Article By: Tiffany Kongpachith

This guide is designed to give users insight on how to set up and configure SAML Federation to Microsoft Office 365 with CA Single Sign-On (SSO). CA Single Sign-On in this integration will be the Identity Provider (IdP) while Office 365 will be the Service Provider (SP).

Note: Microsoft Office 365 does not support SAML Federation standalone unless you have Azure Active Directory (AAD). You MUST HAVE Azure Active Directory to do any SAML Federation whether it is to be configured as Microsoft Office 365 is the Identity or Service Provider.

Prerequisites

Note: Before proceeding with the Federation, please refer to the instructions below.

The Office 365 quick-connection template uses SAML 2.0 metadata from Office 365 to configure SSO endpoints and other information. Download the Office 365 metadata XML file before creating the Office 365 connection.

  1. Obtain the SAML 2.0 Metadata for Office 365 
  2. Save the XML file to a desired location.

Ensure to extract the certificate under the <X509Certificate></X509Certificate> and save the file into Notepad then change the (.txt) extension to a (.pem) extension.

  1. Make sure when you save the certificate you add the following two (2) lines before and after the certificate. 

For example:

  • Make sure to have an Office 365 Administrator account to log into.
  • Make sure to have Azure Active Directory linked to your Office 365 account in order to provision and manage users from your local Active Directory onto Office 365.
  • Ensure to create user accounts that you want to Federate into Office 365 Admin Center.
  • The CA Access Gateway is preconfigured, and the endpoints are set for Federation.
  • Set up the CA Single Sign-On to create a Session Store. Follow these instructions.

SAML Metadata Certificate and CA Single Sign-On Policy Server

1. Log into the SiteMinder Administrative User Interface (UI).

2. Navigate to Tasks > Infrastructure > X509 Certificate Management > Trusted Certificates and Private Keys.

3. Under the Trusted Certificates and Private Keys, click the Import New option.

4. Import the (.pem) certificate by clicking the Browse button and locating the stored certificate. Once it is selected, click Next.

5. You can define the alias name for the certificate under the Select Entries section. Then click Next.

6. Review the certificate’s properties and alias name you define. Once you have reviewed this, click Finish. You should now be redirected back to the Trusted Certificates and Private Keys screen and see the new certificate was added.

Create an Entity in CA Single Sign-On Policy Server

1. If you are not logged in still, log into the CA Single Sign-On Policy Server Administrative UI.

2. Navigate to Tasks > Infrastructure > Federation > Partnership Federation > Entities.

3. To ensure that data is not misconfigured, we want to manually create an entity versus importing metadata. Once on the Entities screen, click Create Entity.

4. For Entity Location, select Remote. For New Entity Type, select SAML2 SP. Click Next.

5. The required fields for an Entity are marked in red. Requirements are the Entity ID and Entity Name.

6. If you overview the SAML Office 365 metadata file, you will need to locate the entityID=”” parameter of the <EntityDescriptor> line (initially found on the first line).

For example: entityID=”urn:federation:MicrosoftOnline” Note: This is the value that you will need to put in the Entity ID field on the Entity configuration.

7. For the Entity Name, you may define this. We would recommend the name as “Office365.”

8. Refer back to the metadata, look for the URL of the Assertion Consumer Service located under the tag <AssertionConsumerService> for Location=”” after the NameIDFormat.

For example: Location=https://login.microsoftonline.com/login.srf
Note: You are able to include more ACS URLs by clicking the Add Row button

9. That same <AssertionConsumerService> line you will find the Bindings=”” needed to be configured.

For example: Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST”

10. As well as the Index value for the Binding; index=””

11. You can configure if it will be Default or not with the checkbox.

12. Under the Signature and Encryption Options, for Verification Certificate Alias – select the SAML metadata certificate you extracted and saved. For Encryption Certificate Alias, select the signing certificate of the Policy Server.

13. Refer back to the Metadata, look for the <NameIDFormat> for what naming formats Office 365 requires with checkboxes. Note: You are configuring SAML2.0 formats – so this indicates it supports Transient and Persistent. (You may add any additional naming formats) Then click Next.

For example:

<NameIDFormat>
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
</NameIDFormat>
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<NameIDFormat>
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
</NameIDFormat>
<NameIDFormat>
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
</NameIDFormat>
<NameIDFormat>
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
</NameIDFormat>

14. Once these configurations are correct from the SAML metadata, then click Finish. You will be redirected back to the Entities screen to see the new Entity was added.

Create a Federated Partnership in CA Single Sign-On Policy Server:

1. If you are not logged in still, log into the SiteMinder Administrative User Interface (UI).

2. Navigate to Tasks > Infrastructure > Federation > Partnership Federation > Partnerships.

3. Click Create Partnership.

4. From the Create Partnership drop-down, select SAML SP.

5. Give the Partnership a Name value.

6. For Local IDP ID, select the URL that is set to your IDP from the drop-down list.

7. For Remote SP ID, enter the Entity ID that was defined and set in the Entity as well as within the metadata from the drop-down list. Ex: urn:federation:MicrosoftOnline

8. Under User Directories, from the User Directories stored within the Policy Server – select or highlight the Directories from the Available Directories column and click the single arrow to move to the Selected Directories column. This will be the user directory that Single Sign-On will pull for authentication.

9. (Optional) You may configure Time Restrictions by expanding the little down arrow. You may select a begin date and an end date for the Partnership. Each day of the week (Monday-Sunday) will have a row with checkboxes for each hour (12AM-12PM // 12 HR) for the Allowed Times. If they are unchecked, they are considered Restricted Times/Days.

10. (Optional) You may configure IP Restrictions by expanding the little down arrow. Click Add row to fill in the field for Entry Type, IP Address, Subnet Mask, End of Range, Host Name, and Delete (checkbox).

11. Once you have configured the Partnership, click Next.

12. The next section of User Identification screen from the selected Directory, you can configure the User Class to allow All Users in the Directory or by User, Group, Organization Unit, Filter User Property, Filter Group Property, Filter OU Property, or Filter Any. In the User Name / Filter By you can filter to your specifications. Enabled or disable whether to Exclude your configurations or Delete the row itself for Federated Users. Once complete, click Next.

13. The next section of Assertion Configuration screen, under the Name ID section define the following required values, Name ID Format, Name ID Type, and Value. The attribute placed in the Value field will be where to store the ImmutableID that Microsoft generates as a unique identifier to its users. (You will view those configurations more in detail later on.) Click Next.

14. The SSO and SLO screen under Authentication, the fields need to be ensured is the Authentication Mode is set to Local. Be sure to include an Authentication URL in the field below. The Authentication Class ensures that it is set to urn:oasis:names:tc:SAML:2.0:ac:classes:Password.

15. Under SSO, make sure the Authentication request Binding is enabled to HTTP-POST. For SSO Binding enable HTTP-POST. Transaction Allowed is Both IDP and SP initiated. Make sure the Remote Assertion Consumer Service URLs is the same set as previously in the Entity.

Index = 0, Binding = HTTP-POST, URL = https://login.microsoftonline.com/login.srf , Default – Yes

16. You may overlook the other configuration sections otherwise click Next.

17. Under the Signature and Encryption screen underneath the Signature subsection, the Signing Private Key Alias should be the signing certificate of the Policy Server. The Signing Algorithm should be RSAwithSHA1. The Post Signature Options is set to Sign Assertion.

18. Underneath the Verification section, set the Federation certificate from the metadata that you extracted (and gave an alias name for) as the Verification Certificate Alias. You can also ser the secondary verification certificate alias as the same.

19. You do not have to set an Encryption Certificate. You may if needed. Otherwise, click Next.

20. On the Confirmation screen, check and overview all configurations prior to proceeding. Once you have, click Finish.

21. Returned to the Partnerships page, if it is not already set, find the Partnership that was just created and hover over Action, click the Activate option to activate the Partnership. Click Yes.

22. Check to see that the Status of the Partnership shows Active.

Microsoft Office 365 and Azure Active Directory

(Note: Before you begin, ensure that your Office 365 has a product license for both Office 365 AND Azure Active Directory. i.e. Office 365 E1 + Azure Active Directory Premium P1)

1. Go to http://office.com or https://portal.office.com to log into the Office 365 Admin account.

Note: Must log into Office 365 with your non-domain account, typically ending with[email protected]

2. Once logged in, locate the Admin module under Apps to enter the Admin Center.

3. Locate on the Admin Center for the Users/Active Users.

4. Once on Active Users, click Add a User to create a User from your Local AD Domain onto Office 365.

5. Fill out the required fields for a new User: First name, Last name, Display name, Username, and select the Domain that is NOT the .onmicrosoft.com and lastly give a Password.

6. Now log into Azure Active Directory or click this link with your same Office 365 account credentials.

7. At the top of the search bar on the Azure Dashboard, search for “Users.”

Note: You will see that the recent User created in Office 365 was NOT created on Azure AD

8. Click New User.

9. Enter the required fields: Name, Username, and what Directory Role the User is. 

(You may enter additional information in the Profile, Properties, and Group sections)

10. Once completed, click Create.

11. You should see the User was successfully created on Azure Active Directory.

Windows PowerShell with Office 365 and Azure Active Directory

1. Open the Windows Start menu, type in the search bar “Windows PowerShell” and Run as Administrator.

2. Type in the command, “Connect-MsolService” to initiate a connection to Azure Active Directory.

3. The command will prompt an Office 365 login, type in the Administrator account email with the domain, “.onmicrosoft.com”, and the credentials.

4. Run the list of commands below to set variables. This PowerShell script uses the custom domain configured of <desire-domain.com>. You will need to replace that in the script with your own custom domain.

Windows PowerShell to Check for a User’s ImmutableID

Microsoft Office 365 auto-generates ImmutableIDs to each of its users that are provisioned in Azure Active Directory.

1. Open the Windows Start menu, type in the search bar “Windows PowerShell” and Run as Administrator.

2. Type in the command, “Connect-MsolService” to initiate a connection to Azure Active Directory.

3. The command will prompt an Office 365 login, type in the Administrator account email with the domain, .onmicrosoft.com, and the credentials.

4. Type in the command: Get-MsolUser -All | Select ImmutableID, UserPrincipalName, DisplayName

Note:This displays the Base 64 encoded string aka the ImmutableID is a specific attribute for an Office 365 object that is synchronized from on premise Active Directory. Office 365 uses a special method to convert on-premise user ObjectGUID to another string and save the string as ImmutableID

5. Copy the ImmutableID value (please refer back to Step 5.12; recall the Partnership configurations > Assertion Configuration screen, you were prompted to enter a user attribute value. This attribute would be where the ImmutableID would be stored and pull in the Partnership). i.e User Attribute > Value = employeeName

6. Connect to your Local Active Directory and copy the ImmutableID value of each user and Paste the base 64 string attribute in the corrective attribute set from the Partnership previously.

7. Once this is complete, try to log back into Office 365. http://portal.office.com or http://office.com

8. Log in with a user account that is on all platforms: on-premise Active Directory, Office 365, and Azure Active Directory with their associated ImmutableIDs stored in their profile.

Note: If you have CA Single Sign-On to protect the URL, then enter in the userID and Password)

9. If it succeeds, great! If not, try again with another user account.

You have successfully accomplished SAML Federation with Office 365!

Looking for additional help with Broadcom/CA Technologies and SSO? ISX Consulting is an elite IAM security firm that offers boundless expertise in a range of cybersecurity and business process services, including Broadcom and CA Identity suite and more. Take your interoperability to the next level, and contact an ISX consultant today.

ISXBroadcom/CA Technologies Single Sign-On (SSO) to Use SAML Federation to Microsoft Office 365

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *