Configure RSA Cloud Authentication Service

1. Sign in to RSA Cloud Administration Console.

2. Click Authentication Clients > Relying Parties.
3. On the My Relying Parties page, click Add a Relying Party.

4. On the Relying Party Catalog page, click Add for Generic OIDC.

5. On the Add OIDC Basic Information page, enter a name and description for the relying party and click Next Step.
6. On the Authentication page, choose SecurID manages all authentication.
7. In the Primary Authentication Method list, select your desired login method as either Password or SecurID.
8. Select the assurance level you want to use in the options available in 1.0 Access Policy for Additional Authentication.
9. Click Next Step.
10. On the OIDC Relying Party Connection Profile page, complete the fields to specify the connection information for the Cloud Authentication Service as the provider and OpenID Connect (OIDC) as the relying party.
    1. The Authorization Server URL will be auto populated. This URL is used on the Idera ER/Studio Team Server side.
    2. The Redirect URL is to be obtained from Idera ER/Studio Team Server and follows the format: http(s)://<Server IP or FQDN>:<Port>/azureSSO/rsacode (for example, https://QE-01:8443/azureSSO/rsacode).
       • The 'Port' is obtained during the initial installation of the product.
       • Please note that 'azureSSO' serves as a placeholder in Idera ER/Studio Team Server.
    3. Provide a Client ID.
    4. Select Client Authentication Method as 'CLIENT_SECRET_BASIC'.
    5. Provide a Client Secret or generate one.
    6. Provide the scope as 'openid' (Scopes should be added beforehand. See Notes section). 
    7. Provide the claims as 'email' and 'username' (Claims should be added beforehand. See Notes section).
11. Click Save and Finish.

Notes

1. In the RSA Cloud Administration Console navigate to Access > OIDC Settings.
2. On the Scopes page, type openid in the available field, and then click Save Settings.

3. On the Claims page, add the claim name. It is important that the name you use matches the one used in the Idera ER/Studio Team Server Configurator page.
4. In the Select Source field, choose one of the following options:
   • Identity Source: This dynamic field requires a user-provided value during SSO login. If the user is not listed in the Idera ER/Studio Team Server identity source, the system checks the user’s email address to either create a new account or authenticate an existing one.
   • Constant: This static field uses a fixed value during SSO login. If the user is not listed in the Idera ER/Studio Team Server identity source, the system checks the user’s email address to either create a new account or authenticate an existing one.  
5. The behavior of Value field depends on the Select Source options:
   • Constant displays an input box for entering strings.
   • Identity Source shows a dropdown list with values from the existing identity source.
6. Click Save Settings.
7. Publish your changes.

Configure Idera ER/Studio Team Server

1. Log in to the Idera ER/Studio Team Server admin console.
2. An administrator must first activate Single Sign-On (SSO). To do this, navigate to the Single Sign-On page in the left-side menu. Check the Use SSO checkbox to enable SSO. Once this is done, additional options for selecting and configuring SSO will become available.
3. Select RSA Secure ID from the drop-down list under the Select SSO Provider options.

4. The appropriate provider will appear.

5. The following fields are available when configuring SSO with RSA:
   • DomainId: Authorization Server Issuer URL provided by RSA. This is the highlighted portion of the URL.
   • ClientId: Use the Client ID from the RSA connector configuration.
   • Client Secret: Use the Client Secret from the RSA connector configuration.
   • Claim: Email: This field must match the entry in the RSA console. Otherwise, you will receive an error when attempting to log in.
   • Claim: User Name: This field must match the entry in the RSA console. Otherwise, you will receive an error when attempting to log in.
   • Proxy Server Details: Check this box if your machine uses a proxy server. Server details will be auto-filled. To modify any of these details, use the admin account.

Note: Most users utilize a proxy server, which may be configured with either HTTP or HTTPS protocols. The following details pertain to the HTTPS configuration of the proxy server. You have the option to select the protocol that aligns with your proxy server’s configuration, whether it is HTTP or HTTPS.

6. After completing all necessary fields, click Test to verify your entries. All responses to these tests are recorded in the sso.log file.
7. If all details are correct, the Update button will be enabled. Clicking this button encrypts the information and saves it in a property file, after which Team Server restarts. Once the restart is complete, the Login by SSO button will be enabled on the Login page.

Notes

• If you interchange the values entered in the Claim: Email and Claim: User Name fields, you can still log in through RSA, but the values will appear interchanged in your profile under People.
• If your ClientId or Client Secret is incorrect, or if your redirect URL fails, you will not receive any logs. Instead, an RSA page will display the error message: Invalid request.
• Team Server includes a Test button to help you avoid connection problems. When you click Test, Team Server performs the following checks:
  1. Network Reachability: Checks if the SSO provider is reachable over the network.
     • If this check fails, ensure that:
       1. Your Team Server has access to the internet.
       2. There are no firewalls blocking HTTP traffic for your Team Server.
       3. The settings are correctly configured in your proxy server (if applicable).
  2. Proxy Server Reachability: Checks whether the SSO provider is reachable through a proxy server (if applicable).
     • If this check fails, verify that the proxy server settings are correct.
  3. Check that the Client ID and Secret credentials are accepted by the SSO provider.
     • If this check fails, verify the following:
       1. The details are correct (involve your SSO Identity Provider administrator).
       2. The configuration settings match those in the SSO Portal.
       3. The Client ID and Client Secret are obtained from the corresponding app registration.
       4. The redirect URIs are correct.
       5. You can obtain a metadata file from the application registration pages of the Identity Provider portal. Check the metadata file and compare it with any other working SSO applications on the client side.