# Sitefinity Configuration Guide This guide describes how to configure Sitefinity for Single Sign On (SSO) scenarios with Rhythm. The basic configuration will allow you to authenticate users using Auth0 for SSO. However, Auth0 has no knowledge of the user’s membership or other statuses within Rhythm. By completing both the basic and role configuration, Sitefinity will automatically assign Sitefinity roles to users for each Rhythm Portal [Security Policies](/guides/security-policies) for which they qualify. Security Policies You can create `security policies` for active members, committee members, or other ad-hoc eligibility requirements. See the [Security Policies](/guides/security-policies) guide for more info. Sitefinity Version The instructions below apply to **Sitefinity 14.3 and earlier** (including Sitefinity 13.3 LTS). If you are using **Sitefinity 14.4 LTS or later** (including any 15.x release), the configuration steps are different because Progress removed the internal IdentityServer3 and the legacy OpenID/SWT/Forms authentication modes in version 14.4. Skip ahead to [Sitefinity 14.4 LTS and Later Configuration](#sitefinity-144-lts-and-later-configuration) for the updated steps. ## Prerequisites To enable SSO, you will need to know your Auth0 Domain and Client ID. You can get these values by submitting ticket in [ZenDesk](https://support.rhythmsoftware.com). Please indicate that you need this information to configure SSO in Sitefinity so the Rhythm team can enable the Sitefinity integration for your client. This configuration requires a version of Sitefinity that is covered under Long Term Support (LTS). Please see the [SiteFinity's Lifecycle Policy](https://www.progress.com/support/sitefinity-lifecycle-policy) page to confirm that your version is not **Retired**. ## Basic Configuration The configuration in this section will enable users to authenticate with Sitefinity using their Rhythm credentials stored in Auth0. Start by navigating to the settings of your Sitefinity site and toggle to **Advanced** settings. Next, in the left menu navigate to **Authentication > SecurityTokenService > AuthenticationProviders > OpenIDConnect** and set the following values: * `Client ID`: This should be the Auth0 Client ID supplied by Rhythm support * `Authority`: This should be the Auth0 Domain supplied by Rhythm support * `Redirect URI`: This should be the URL of your site in the format: "http://`[your-site-url]`/Sitefinity/Authenticate/OpenID/sitefinity" After this configuration, the OpenIDConnect settings should look like the following: ![Configure OpenIDConnect 1](/assets/openidconnect1.fab26abedd27e049171ef799a5db4cd1587ee5ff55cbf92f04d3f3ef909fe09c.2912e2f7.png) ![Configure OpenIDConnect 2](/assets/openidconnect2.81d5ae665c85450abaf32c09e4080e1cc0f7b3101f6da5e7e3f972297097ce16.2912e2f7.png) ![Configure OpenIDConnect 3](/assets/openidconnect3.c1a7e71c9fedb2e68ebf9d3d7e0de65398276a8ee584d533f11004b616288e2e.2912e2f7.png) At this point, resetting your site using **iisreset** should enable SSO. We recommend testing this now, even if you decide to continue to enable role assignment. ## Role Assignment This configuration is optionally used when you want to automatically assign roles to users based on `security policies` in Rhythm. ### Security Policies Start by configuring the `security policies` in Rhythm that you want to use to assign users to roles in Sitefinity. You have a wide range of options on how to segment your users and can create as many `security policies` as you would like. As you create each `security policy` it will be assigned an `ID`. Make note of these `ID`s as we will need them later. You can see an example `ID` in this screenshot: ![Security Policy](/assets/securitypolicy.fbfb3a5cdc5235ef47b23804a5286dd34da473e2dbc9af33416ecf1841df364f.2912e2f7.png) ### Scope Return to the settings of your Sitefinity site and toggle to **Advanced** settings. Next, in the left menu navigate to **Authentication > SecurityTokenService > IdentityServer > Scopes** and create a new scope with the following values: * `Scope Name`: *"securityProfiles"* * `Claims`: This should be a comma separated list with each `security policy` you want to assign to a Sitefinity role. Using the `security policy` `ID`s you noted above, the claim for each `security policy` should be formatted like: "http://rhythmsoftware.com/sitefinity/`[security-policy-id]`" Once complete, your new scope should look like: ![Scope](/assets/scopes.0bcecab3f961e9f9a05322dd30dc86985fd900037336840f470add29d6601513.2912e2f7.png) You will now need to add this scope to the configuration in several locations. #### Sitefinity Client Next, in the left menu navigate to **Authentication > SecurityTokenService > IdentityService > Clients > sitefinity**. Add the new *"securityPofiles"* scope you just created to the `Allowed Scopes` as in the screenshot below: ![Client](/assets/sitefinityclient.5e166a19e67dcd567b318a1895cb0c5480510345cbd89e5afb429e3b1d13b79b.2912e2f7.png) #### OpenIDConnect Configuration Next, in the left menu navigate back to **Authentication > SecurityTokenService > AuthenticationProviders > OpenIDConnect** and add the new *"securityProfiles"* scope to the `Allowed Scopes` as on the screenshot below: ![Configure OpenIDConnect 4](/assets/openidconnectupdated.199f4b17346487c787fe732ac0ff941aca6020195f289e84a27639591a997b10.2912e2f7.png) ### Relying Party Next, navigate to **Authentication > RelyingParty** and add the new *"securityProfiles"* scope to the `Additional scopes of claims to be requested from STS` as in the screenshot below: ![Relying Party](/assets/relyingparty.029977be619184a4720b7bb6073d10da4f5073aca821d4e9467576978900e021.2912e2f7.png) ### Claims to Role Mappings Finally, we are going to map the claim for each `security profile` to a Sitefinity role. Start by navigating to **Authentication > RelyingParty > Claims to role mappings**. For each `security policy` you want to map to a Sitefinity role, add a new mapping with the following values: * `Name`: The name of the Security Policy * `Claim type`: One of the `security policy` claim values you specified above in the format: "http://rhythmsoftware.com/sitefinity/`[security-policy-id]`" * `Claim value`: *"active"* * `Mapped roles`: One or more existing Sitefinity roles that users should be assigned if the `security policy` applies to them Each mapping should look like the following screenshot: ![Claim to Role](/assets/claimtorole.0b5301f3839868636bb206a98761118d9a9bfb0d57ba2bc8d8f9867203555a97.2912e2f7.png) Once all of your configuration is complete, you need to perform an **iisreset** to enable the new configuration. At this point, users should be assigned Sitefinity roles each time they log in. Please be aware, Sitefinity does **not** show roles assigned by claims in the User Administration area. If you look at a user who has logged in, all roles will always be unchecked. However, the roles will be assigned dynamically each time the user logs in. For more information see this [help article](https://community.progress.com/s/article/claims-to-roles-mapping-not-adding-roles-to-users) ## Sitefinity 14.4 LTS and Later Configuration The instructions in this section apply to **Sitefinity 14.4 LTS and later**, including all Sitefinity 15.x releases. Use this section if your Sitefinity version is 14.4 or newer. What changed in Sitefinity 14.4 In Sitefinity 14.4 (March 2023), Progress removed the legacy OpenID, SWT, and Forms authentication modes along with the internal IdentityServer3 package. The "Default" authentication protocol (introduced in 14.0 and made the default in 14.1) is now the only option. As a result, Sitefinity no longer acts as its own STS. The `securityProfiles` scope is now defined in Auth0 (managed by Rhythm) rather than inside Sitefinity, and Sitefinity acts purely as a relying party that delegates authentication to Auth0. ### Prerequisites To enable SSO, you will need to know your Auth0 Domain and Client ID. You can get these values by submitting a ticket in [ZenDesk](https://support.rhythmsoftware.com). Please indicate that you need this information to configure SSO in Sitefinity so the Rhythm team can enable the Sitefinity integration for your client. This configuration requires a version of Sitefinity that is covered under Long Term Support (LTS). Please see the [Sitefinity Lifecycle Policy](https://www.progress.com/support/sitefinity-lifecycle-policy) page to confirm that your version is not **Retired**. As of this writing, supported LTS versions include Sitefinity 14.4 LTS and Sitefinity 15.4 LTS. Default authentication protocol If you are upgrading from an older version of Sitefinity, confirm that the **Default** authentication protocol is selected before continuing. Navigate to *Administration » Settings » Advanced » Authentication* and ensure the *Authentication* dropdown is set to *Default*. This is the only supported option in 14.4 and later. ### Basic Configuration The configuration in this section will enable users to authenticate with Sitefinity using their Rhythm credentials stored in Auth0. Start by navigating to the settings of your Sitefinity site and toggle to **Advanced** settings. Next, in the left menu navigate to **Authentication > SecurityTokenService > AuthenticationProviders > OpenIDConnect** and set the following values: * `Client ID`: The Auth0 Client ID supplied by Rhythm support * `Client Secret`: The Auth0 Client Secret supplied by Rhythm support (required for authorization code flow) * `Response type`: `code` (recommended — authorization code flow) * `Authority`: The Auth0 Domain supplied by Rhythm support * `Metadata address`: Leave blank to use the default (`{Authority}/.well-known/openid-configuration`) * `Allowed scopes`: `openid email` at minimum (the `securityProfiles` scope is added in the Role Assignment section below) * `Redirect URI`: The URL of your site, for example `https://[your-site-url]/` * `Use PKCE`: Enabled (recommended when using `code` response type) Authorization code flow with PKCE Progress now recommends authorization code flow with PKCE as the most secure option. The legacy implicit flow (`response type = id_token`) is still available but is no longer recommended for new configurations. Select the **Enabled** checkbox and save your changes. At this point, resetting your site using **iisreset** should enable SSO. We recommend testing this now, even if you decide to continue to enable role assignment. ### Role Assignment This configuration is optionally used when you want to automatically assign Sitefinity roles to users based on `security policies` in Rhythm. How role assignment works in 14.4+ In Sitefinity 14.4 and later, the `securityProfiles` scope is defined in Auth0 and is fulfilled by a Rhythm-managed Auth0 post-login action. When Sitefinity requests the `securityProfiles` scope at login, the action calls Rhythm to look up which `security policies` the user qualifies for and adds a claim of the form `http://rhythmsoftware.com/sitefinity/[security-policy-id]` with value `active` to the ID token for each one. The Auth0 action is configured by Rhythm support as part of your tenant setup — you do not need to configure anything in Auth0 directly. Your only responsibility is to (1) tell Sitefinity to request the `securityProfiles` scope and (2) map the resulting claims to Sitefinity roles. #### Security Policies Start by configuring the `security policies` in Rhythm that you want to use to assign users to roles in Sitefinity. You have a wide range of options on how to segment your users and can create as many `security policies` as you would like. As you create each `security policy` it will be assigned an `ID`. Make note of these `ID`s as we will need them later. #### Request the securityProfiles Scope Return to **Authentication > SecurityTokenService > AuthenticationProviders > OpenIDConnect** and add `securityProfiles` to the `Allowed scopes` field (alongside `openid email`). Save your changes. This causes Sitefinity to include `securityProfiles` in the scopes it requests from Auth0 at login, which triggers the Rhythm post-login action to enrich the token with the user's security policy claims. #### Claims to Role Mappings Finally, map the claim for each `security policy` to a Sitefinity role. Navigate to **Authentication > RelyingParty > Claims to role mappings**. For each `security policy` you want to map to a Sitefinity role, click **Create new** and add a new mapping with the following values: * `Name`: The name of the Security Policy * `Claim type`: The claim value in the format `http://rhythmsoftware.com/sitefinity/[security-policy-id]` * `Claim value`: `active` * `Mapped roles`: One or more existing Sitefinity roles that users should be assigned if the `security policy` applies to them Save your changes. Once all of your configuration is complete, perform an **iisreset** to enable the new configuration. At this point, users should be assigned Sitefinity roles each time they log in. Please be aware, Sitefinity does **not** show roles assigned by claims in the User Administration area. If you look at a user who has logged in, all roles will always be unchecked. However, the roles will be assigned dynamically each time the user logs in. For more information see this [help article](https://community.progress.com/s/article/claims-to-roles-mapping-not-adding-roles-to-users).