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

Configure CAS

Perform these steps to configure CAS as Relying Party to Microsoft Entra ID.
Procedure

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

3. Click Add a Relying Party.

4. From the Relying Party Catalog, select 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 Entra 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 (For example, "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 (For example, "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, and get Entity ID text field value as it will be needed in Microsoft Entra configuration.

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

After publishing, your application is now enabled for SSO. 

20. Click Save and Finish.

Configure Microsoft Entra

1. Log in to Microsoft Entra admin center with admin credentials at https://entra.microsoft.com/
2. From the left panel, go to Settings > Domains to verify your custom domain name.

3. Run Windows PowerShell as an administrator and connect to your Microsoft Entra with the following command. You need to login with your Microsoft Entra Tenant administrator account.

Note: This admin account should be in a separate domain than the one that will be federated (e.g. The admin should be a member of the default domain that is provided by Microsoft).

  Connect-MgGraph

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

Get-MgDomain

5. 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.
• 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.).

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

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

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

User Experience

Scenario A:

1. Go to Entra ID applications portal: https://myapps.microsoft.com/
2. User should enter his email address in the domain already federated with RSA. User then will be redirected to CAS to be authenticated.

3. User enters the User ID and Password for authentication with RSA.

4. After successful authentication, the user will be redirected to Microsoft Entra portal hosting the applications.

Scenario B:

1. User can choose to directly access the application hosted on Microsoft Entra without accessing from the applications portal. For testing purposes of this integration, DocuSign has been configured with Microsoft Entra.
2. The User enters the email address in the federated domain and then will be redirected to Microsoft which will redirect the user to CAS portal to be authenticated.

Note:

• Optionally the organization can give their users the direct application link that is hosted on their Microsoft Entra tenant which will have them skip entering the email address in DocuSign as a first step which enhances the login experience for users.
• Administrators can find the direct link for applications by accessing the Microsoft Entra Admin Center. From the left pane, navigate to Identity -> Applications -> Enterprise Applications -> User access URL.

3. User enters the User ID and Password for authentication with RSA.

4. After successful authentication, the user will be redirected to DocuSign home landing page.

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.