Microsoft 365 - SAML and SCIM Relying Party Configuration - RSA Ready Implementation Guide
6 months ago

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

 

Configure CAS as SCIM Server

Perform these steps to configure the following. 

  • CAS as a SCIM server.
  • CAS using SAML Relying Party.

Procedure 

    1. Sign in to the RSA Cloud Administration Console.
    2. Navigate to Users > Identity Sources > Add identity source.

    1. On the New Identity Source page, select Azure Active Directory (SCIM).
    2. In the Identity Source Details section,  enter Identity Source Name and description (Optional). Take note of the SCIM Service Provider Base URI and the API key that will be used in Microsoft Entra to complete the connection.
    3. Click Save,  and then click Publish Changes.

    1. In the Password Creation section, select RSA Unified Directory as the Password Type and set RSA Password to Required.

    1. Click Save.

     

    CAS using My Page SSO 

    1. Sign into RSA Cloud Administration Console.
    2. Select the Authentication Clients > Relying Parties.

    1. Click Add a Relying Party.

    1. From the Relying Party Catalog, select Add for Service Provider SAML.

    1. On the Basic Information page, enter a name for the Service Provider in the Name field
    2. Click Next Step.
    3. On the Authentication page, select SecurID manages all authentication.
    4. From the 2.0 Access Policy for Authentication dropdown list, select a policy that was previously configured.

    1. Click Next Step.
    2. On the Connection Profile page, navigate to Data Input Method and select Enter Manually

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

    1. Audience for SAML Response: Keep the Audience for SAML Response unchanged as it remains the default setting.

    1. Go to the Message Protection section, click Download Certificate to download the IDP signing certificate used by Cloud Authentication Service to sign the assertion. This will be required in the Microsoft 365 configuration.

    1. In the User Identity section, select persistent from the Identifier Type dropdown list. 
    2. From the Property dropdown list, select externalId.

    1. 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.

    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.

    1. Go to the Identity Provider section and 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 365 configuration.

    1. Click Save and Finish.
    2. Click Publish Changes and wait for the process to finish.
    3. After publishing, your application is now enabled for SSO. 

    Configure Microsoft 365

    This section describes how to configure the following: 

    • Microsoft Entra as a SCIM client for CAS.
    • Microsoft Entra with CAS using SAML Relying Party.

    Procedure

    Microsoft Entra as a SCIM Client

    1. Sign in to Microsoft Entra Admin Console.
    2. From the left panel, navigate to Applications > Enterprise applications.

    1. Click New Application.
    2. Select Create your own application, and enter a name for the app.
    3. Choose Integrate any other application you don't find in the gallery (Non-gallery).
    4. On the Getting Started page, click Get started in the Provision User Accounts section.

    1. Click New Configuration.
    2. In Tenant URL, use SCIM Service Provider Base URI copied from CAS.
    3. In Secret Token, use the API key generated from CAS.
    4. Click Test connection. You should receive a message that the connection has been established and tested successfully.
    5. Expand the Mappings section.

    1. Click Provision Microsoft Entra ID Groups and disable it. 

      1. Go to the Mappings section, and click Provision Microsoft Entra ID Users.
      2. Enable Provision Microsoft Entra ID Users. 
      3. In the Target Object Actions section, select CreateUpdate, and Delete. This configuration allows you to create users, update their attributes, and delete them from Microsoft Entra ID, with changes synchronized to CAS.

      1. In the Attribute Mapping section, map the attributes as shown in the figure. You can edit, delete, or create new mappings between Entra ID and RSA by clicking on each attribute.

      1. Go back to the Provisioning page, and ensure the Provisioning Status is turned on.

      1. By default, changes made to users in Microsoft Entra are automatically synchronized with CAS every 40 minutes.
      2. To apply changes immediately, select Provision on Demand on the left pane and enter the user's name. Ensure the users are listed in the Users and Groups tab.

      Microsoft Entra using SAML Relying Party

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

        1. You will be redirected to Microsoft 365 admin center.
        2. Go to Settings Domains Add domain to verify your custom domain name which should be federated.

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

        1. In 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.

        1. Run Windows PowerShell as an administrator and connect to your Office 365 instance with the following command. 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

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

        Get-MgDomain

        1. 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 – My Page).
          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.
        • Note: If you are 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.).

        1. 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" 

        1. 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. 

        1. 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 *

        Notes

        • 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 users who will authenticate via SAML must have an ImmutableID set. Users without an ImmutableID will not be able to sign in using SAML. You can list all users under the federated domain along with their ImmutableID using the following command: 

        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.