Implement custom external identity providers
The following article demonstrates the minimum configuration required to successfully authenticate a user in Sitefinity CMS STS, using Implicit flow. You first register the provider in Sitefinity CMS backend and, then, implement the provider.
You implement and configure the custom external authentication provider. You create a custom AuthenticationProvidersInitializer where you configure the external provider and then register the initializer in the ObjectFactory.
Register custom external identity provider
To do this, perform the following:
- Navigate to Administration » Settings » Advanced.
- In the left pane, expand Authentication » SecurityTokenService » AuthenticationProviders.
- Click Create new » AuthenticationProviderElement.
- Enter the Name and the Title of the provider.
In this example, enter CustomSTS
- Select Enabled checkbox.
- Save your changes.
The provider is created.
If required, you can configure additional parameters of the provider, instead of hard coding them.
- Under the newly created provider, expand Parameters and create the following parameters:
|The client ID configured in the external STS.
|The absolute path to the external STS.
|The absolute path to the local STS.
NOTE: Make sure the path is added in the external STS during client registration. The path, configured in the external STS, must be identical to the value of the redirectUri parameter.
|Set the value to "id_token"
|Set the value to "openid profile rememberMe email"
|The text that is displayed on the login button.
If you do not enter text, the button is not displayed.
- Save your changes.
Implement the external identity provider
You implement and configure the custom external authentication provider. You create a custom
AuthenticationProvidersInitializer where you configure the external provider and then register the initializer in the ObjectFactory.
Once a user logs via SSO with the STS in the relying party instance, in case there is no user previously authenticated with the same email, a new local user account is automatically created. The profile fields of the account are populated with the information provided by the STS in the claims that are returned. Profile fields of the local account (in the relying party instance) are updated only when they are empty and only from the claims received by the STS. Thus, if you edit your first name in the relying party instance, the change is not synced with the first name on the STS. Once the account is created locally, it is bound to the identity authenticated via email by the STS. If the email is modified either in the STS, or in the local profile in the relying party instance, a new account is once again created for the external user when they log in. If this is the case, all local profile information and local application roles are lost.
Use the following sample:
NOTE: Due to nonce validation, this sample works only under HTTPS. You can disable nonce validation with code to work under HTTP for development and testing purposes. For more information, see Troubleshooting Authentication.
Register the initializer in the Global.asax
Register the initializer the following way: