This article describes how to integrate Cloud Access Service (CAS) with Microsoft Office 365 using SAML Relying Party.

Configure CAS

Perform these steps to configure CAS as Relying Party to Microsoft Office 365.
Procedure

1. Sign in to RSA Cloud Administration Console.
2. Navigate to Authentication Clients > Relying Parties.

3. Click the Add a Relying Party button on the My Relying Parties page.

4. From the Relying Party Catalog, click Add for Service Provider SAML.

5. On the Basic Information page, enter a name for the Service Provider in the Name field.
6. Click Next Step.
7. On the Authentication page, select SecurID manages all authentication.
8. From the 2.0 Access Policy for Authentication dropdown list, select your desired policy that was previously configured.

9. Select Next Step.
10. On the Connection Profile page, select Enter Manually.

11. In the Service Provider section, enter the following values:
    1. Assertion Consumer Service (ACS) URL: Enter the Microsoft ACS URL “https://login.microsoftonline.com/login.srf”
    2. Service Provider Entity ID: Enter the Microsoft Issuer "urn:federation:MicrosoftOnline".

12. In the Audience for SAML Response section, keep the Audience for SAML Response unchanged as it remains the default setting.

13. Go to the Message Protection section, click Download Certificate to download the IDP signing certificate used by CAS to sign the assertion. This will be required in the Microsoft O365 configuration.

14. In the User Identity section, select persistent from the Identifier Type dropdown list.
15. From the Property dropdown list, select objectGUID.

16. In the Statement Attributes section, add the following Attributes.
    
    1.  First Attributes
       • Attribute Name > IDPEmail
       • Attribute Source > Identity Source.
       • Property > Enter the name used for the email attribute in your user directory (e.g., "mail")
    2.  Second Attributes
       • Attribute Name > ImmutableID
       • Attribute Source > Identity Source
       • Property > Enter the name used for the object ID guid in your user directory (e.g., "objectGUID")

17. When using SAML 2.0 federation with Microsoft Entra ID, MFA done at the IdP is only accepted if the SAML response includes an MFA AuthnContext in the AuthnStatement. If this is missing or incorrectly configured, Microsoft Entra will assume MFA did not occur, and prompt users to register for Microsoft Authenticator or complete MFA again. The MFA claim can be configured to be included in the assertion as part of the Statement Attributes.
    • Attribute Name – Enter http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod
    • Attribute Source – Select Constant
    • Property – Enter http://schemas.microsoft.com/claims/multipleauthn

Note: While including the Statement Attribute is not a mandatory requirement in the configuration, it is strongly recommended to ensure Microsoft Entra recognizes the upstream MFA and avoids prompting users again.

18. Go to the Identity Provider section, enter a discriminator to ensure the Entity ID is unique.

Note: The discriminator will be appended to the end of the Entity ID URL. Make sure to copy the value in the Entity ID field, as it will be required for the Microsoft O365 configuration.

18. Click Save and Finish.
19. Click Publish Changes and wait for the operation to complete.

20. After publishing, your application is now enabled for SSO. 

Configure Microsoft O365

Perform these steps to configure Microsoft Office 365.
Procedure

1. Log in to Microsoft O365 with admin credentials at https://office.com
2. Click the Admin icon from the left panel.

3. You will be redirected to Microsoft 365 admin center.
4. Go to Settings > Domains to verify your custom domain name.

5. After your domain is verified, click Identity from the left panel. Microsoft Entra admin center page will open automatically.

6. Under Identity > Settings > Domain names, ensure that the domain previously entered is listed on the custom domain names page. If not, click Add Custom Domain to verify your domain.

7. Run Windows PowerShell as an administrator and connect to your Office 365 instance with the command below. You need to log in with your Office 365 Tenant administrator account. Note: this admin account should be in a separate domain than the one that will be federated (e.g. a member of the default domain that is provided by Microsoft). 

Connect-MgGraph

8. Retrieve all domains for the company (verified or unverified) to identify the domain which should be federated.

Get-MgDomain

9. Run the following commands   in a PowerShell environment, most of the values come from CAS configuration section:
   1. domain: Enter the domain identified in the previous step for which you want to enable SSO.
   2. brandName: Provide a name to identify your Identity Provider (e.g., RSA – Relying Party).
   3. IssuerUri: Use the Identity Provider Entity ID configured in CAS.
   4. LogOnUri: Use the Identity Provider Entity ID configured in CAS.
   5. Protocol: Enter “saml”.
   6. certData: Configure the signing certificate by following these steps:
      • Download the certificate and save it to a folder (e.g., C:\Users\my.name\Downloads).
      • Use the following PowerShell commands to process the certificate and assign it to the certData variable.
      • If entering the command manually, ensure the character in "r|n" is a backtick, not a single quote

  $cert = "C:\Users\my.name\Downloads\IDPSigningCertificate.pem"
  $certData = $(Get-Content -Path $cert -Raw) -replace"`r|`n|-----BEGIN CERTIFICATE-----|-----END CERTIFICATE-----",""

• Note: When using these variables, ensure you include the $ symbol before the variable name (e.g., $domain, $brandName, etc.).

10. After defining the parameters, issue the following command. A successful run of command should not return any errors.

New-MgDomainFederationConfiguration -DomainId $domain -DisplayName $BrandName -SigningCertificate $certData -IssuerUri $IssuerUri -PassiveSignInUri $LogOnUri -PreferredAuthenticationProtocol $Protocol-FederatedIdpMfaBehavior "acceptIfMfaDoneByFederatedIdp" 

11. After applying the new domain federation configuration, you will be prompted to provide the internal domain federation ID. To retrieve this value, run the following command: 

Get-MgDomainFederationConfiguration -DomainId "yourdomainname.com"

This will return the internal federation ID required for the configuration process.

12. To verify if the domain is configured successfully, run the following command with your domain name and the result must show the same values as used in the script variables above.

Get-MgDomainFederationConfiguration -DomainId $domain| fl *

Test your application integration

1. Go to Office 365 Sign in page.
2. Enter the email of a test user that utilizes the newly federated domain, and you will be redirected to the Sign in portal.

3. Enter your User ID and Password.
4. After successful authentication, you will be redirected to your Office 365 landing page.

• Ensure that the Microsoft Graph PowerShell SDK is installed and that all necessary permissions have been granted before running these commands.
• Office 365 Single Sign-On (SSO) can only be enabled for domains that have been verified in Microsoft Entra ID.
• SSO is not supported for default “onmicrosoft.com” domains provided by Microsoft.
• If your organization doesn't yet have a custom domain for Office 365, one must be purchased to enable SSO
• When configuring the signing certificate in PowerShell, use the backtick character (`), typically located just to the left of the “1” key on your keyboard.
• If you need to modify any configuration settings made in Windows PowerShell following the federation of the necessary domain, utilize the command "Update-MgDomainFederationConfiguration " rather than "New-MgDomainFederationConfiguration " as the domain has already been federated.
• All the users that will be authenticated via SAML must have an immutableID set. Users that do not show an ImmutableID, will not be able to log in using SAML.

Get-MgUser -All -Property UserPrincipalName,OnPremisesImmutableId | Select-Object UserPrincipalName,OnPremisesImmutableId 

• You can revert-back to non-federated authentication by entering the following command: 

Update-MgDomain -DomainId "yourdomainname.com" -BodyParameter @{AuthenticationType="Managed"}

The configuration is complete.