Configuring Your RSA SSO Provider

Go Up to Setting Up Single Sign On (SSO)

The following steps are specific for environments using RSA as your SSO provider. Note that for every RSA change, make sure to publish your changes by clicking Publish Changes in the upper right corner of the window.

Activating RSA SSO in the Team Server Configurator

An Administrator must activate Single Sign-On (SSO) in the Team Server Configurator Single Sign-On page before options appear for users to select RSA.

Note: If you are configuring HTTPS in Team Server, make sure that you do not use localhost. RSA does support localhost, but some errors can occur. Use machine IP or domain name instead.

To activate RSA SSO in the Configurator

1. In the Configurator, use the available Select SSO Provider drop-down list to choose RSA Secure ID for enablement.

   

   The appropriate provider appears.

   

   The content of the following fields is available when you configure SSO in RSA:

   • DomainId.
   • ClientId. If your ClientId or Client Secret are incorrect or your redirect URL fails, you do not receive any logs. Instead you receive an RSA page with an error message "Invalid request."
   • Client Secret.
   • Claim: Email. This field must be the same as provided in the RSA console or you receive an error when attempting to log in.
   • Claim: User Name. This field must be the same as provided in the RSA console or you receive an error when attempting to log in.
   • Proxy Server Details. Check this box if you use a proxy server for this machine. Details for the server are automatically populated in the appropriate fields. If you want to change any of these fields, use the Admin user account.

   

2. Once you complete all of the necessary fields, click Test to verify your entries. All responses to these tests are collected in the sso.log file.
3. If all of the details are correct, the Update button is enabled. When you click that button, the information is encrypted and saved in a property file, and then Team Server restarts. Once the restart is complete, the Login by SSO button is enabled on the Login page.

Note: If you interchange the values entered in the Claim: Email and Claim: User Name fields, you still can log in through RSA but when viewing your profile in the People, notice that the values are interchanged.

Logging into the RSA Dashboard

To access the RSA Dashboard

• Log in to https://xxxxxxxx/AdminInterface/login?sessionTimeout=true where xxxxxx is the domain provided to you by RSA. Your RSA Dashboard appears, similar to the following image.

  

Configuring claims and scope

Completing the claims and scope requirements are essential parts of configuration. If you do not include openid as a scope, then issues occur as you continue in the authentication process of Team Server.

To configure claims and scope

1. Make sure you are logged in and viewing the RSA Dashboard.
2. In the menu, click Access > OIDC Settings.

   

3. On the Scopes page, type openid in the available field, and then click Save Settings. Note that it is mandatory to add an openid.
4. On the Claims page, add the Claim Name. It in important that whatever name you use is also used in the Team Server Configurator page.
5. In Select source, select one of the following options:

   • Identity Source. This is a dynamic field. The user must provide a value, which is received while fetching user details and during login via SSO. If an account is not created based on the user-provided value in the Team Server Claim Name, the system checks the email address field for the user. Depending on the value, it either creates a new user or authenticates it if the same email address is found in Team Server.
   • Constant. This is a static field. The value field is an input box and whatever you provide in the value field is reflected while fetching user details that are used while fetching user details and during login via SSO. If an account is not created based on the value the user provided in the Claim Name used in the Team Server configuration SSO page, the system checks the email address field for the user. Depending on the value, it either creates a new user or authenticates it if the same email address is found in Team Server.

6. In the Value field, note that it behaves differently depending on the selection in the Select source field. A Constant source results in the Value field being an input box that accepts any string, but if you have an Identity Source selection, the Value is a drop-down containing values from the existing identity source.
7. Click Save Settings when done.
8. Be sure to publish your changes. Then continue to the next topic to configure the relying party.

Configuring the relying party for your access policy

Relying parties are organizations that depend on the user's credentials to process transactions and allow access to information. It in important that you make sure that the Redirect URL is correct. If Team Server is running in a port, make sure to include that information when configuring your relying parties.

The following solutions are currently-acceptable relying parties:

• Epic Hyperdrive
• Generic OIDC
• Microsoft Entra ID
• Any service provider using SAML 2.0

To configure the relying party for your access policy

1. Make sure you are logged in and viewing the RSA Dashboard.
2. In the menu, click Authentication Clients > Relying Parties.
3. On the My Relying Parties view, click Add a Relying Party to begin creating a relying party.

   

4. On the Relying Party Catalog view, click Add on the row for the solution that you want to use. In this example, we used Generic OIDC.

   

5. On the Add OIDC Basic Information page, type a name and description for the relying party, and then click Next Step.
6. On the Authentication page, select the authentication process you want to use. For this example, we selected SecurID manages all authentication.

   

7. Select the Primary Authentication Method you want to use. Note that the user is not required to complete the same method twice if you select the same method included in the additional authentication access policy. For this example, we used Password.
8. Select the assurance level you want to use in the options available in 1.0 Access Policy for Additional Authentication. This option appears when you log into Team Server. For this example, we used, All Users Low Assurance Level. Options include:

   • All Users High Assurance Level. After checking the credentials provided in the Configurator, the system asks the user to enter the user email address and password. Users also are asked to authenticate using their FIDO Security Key, and if they are not already registered, they are asked to register.
   • All Users Medium Assurance Level. After checking the credentials provided in the Configurator, the system asks the user to enter the user email address and password. Users also are asked to verify using an authenticator application.
   • All Users Low Assurance Level. After checking the credentials provided in the Configurator, the system asks the user to enter the user email address and password.

9. Click Next Step.
10. On the Connection Profile page, note that the Authorization Server Issue URL displays your domain or issuer endpoint. This is the area highlighted in the following image.

    

11. Complete the Redirect URL field(s) by typing the URL to which you want your application to redirect after a successful login. The only acceptable format is: [http/https]://[ip/machine domain]:[port]/azureSSO/rsacode Note that you can provide either the IP address or domain of your system.
12. In the Client ID field, type a unique ID that identifies this configuration in both the Cloud Administration Service and the OpenID Connect (OIDC).
13. In the Authorization Code Flow section, select the appropriate Client Authentication Method for this relying party. For this example, we selected CLIENT_SECRET_BASIC, and then followed by generating a client secret using the Generate button next to the Client Secret field.
14. In the Scopes field, use the arrows icon on the right to display a list of available scopes, and then check openid. Remember that you previously created this option in the Scope section. Failure to include this option may result in login issues. Settings related to openid are important to relying parties, such as claims.
15. In the Claims field, use the arrows icon on the right to display a list of available claims, and then check mail and givenName at the least.

    

16. Optional. You can enable the Require user consent for disclosure of private information option and the system asks the user to provide consent to disclose private data to the relying party for additional claims, and enable Allow CORS Authentication to support Cross-Origin Resource Sharing (CORS). If you select the CORS option, type the application's URLs in the fields that appear. Note that the links you added in the Redirect URL fields also are included as part of the COTS URLs you add in this area.
17. Click Save and Finish when done.

Policy notes

• A user can create their own policy and add any rules that they like.
• A policy is specific to an identity source, so make sure that you want the user account that you use or import from an identity source to behave the same as the policy.
• You can add rules targeting specific users or all of the existing users.
• Make sure to configure your policy inside My page or else it uses the default policy.