Configure the OpenID Connect provider
Overview
With Sitefinity CMS, you can configure the out-of-the-box OpenID Connect provider and its parameters and enable authentication via OpenID protocol with third party Security Token Issuer (STS) that supports the protocol.
PREREQUISITES: Configure your application as a client in an external STS.
Configuration procedure
To configure the OpenID Connect provider, perform the following:
- Navigate to Administration » Settings » Advanced.
- In the left pane, expand Authentication » SecurityTokenService » AuthenticationProviders.
- Expand the OpenIDConnect node.
- Enter values or modify the following parameters:
|
Key |
Value |
|
Client ID |
The client ID configured in the external STS. |
|
Client Secret |
Client secret as defined by OAuth 2.0 specs. It is not needed for implicit flow (response type is set to |
|
Response type |
Determines the authorization flow as defined by OAuth 2.0 specs. Default is |
|
Authority |
The absolute path to the external STS. |
|
Allowed scopes |
Enter the scopes, required by your scenario. The minimum required scopes for Sitefinity CMS to work with the OpenID Connect provider are |
|
Metadata address |
Enter the absolute URL from where to retrieves the OpenID metadata. If you leave it empty, the default URL is used: |
|
Redirect URI |
Your Sitefinity Redirect URI: e.g If callback path is provided it must match the callback path. |
|
Callback path |
An optional constrained path, on which to process the authentication callback. If you do not provide a value, the value is generated from the Redirect URI parameter, for example:
|
|
Post logout redirect URI |
You configure this parameter in the settings of the Identity server client of the external STS as a redirect URI. Enter the desired post logout URI from your site, for example,
|
|
Validate OpenIdConnect.nonce cookiе |
Specify whether requests must require OpenIdConnect.nonce cookie for authentication. This option allows local development when browsers require secure transport of cookies with SameSite attribute set to None. For more information, see OpenIDConnect.nonce cookie and SameSite cookie attribute.
|
|
Use PKCE |
Enables or disables the use of the Proof Key for Code Exchange (PKCE) standard. This only applies when the response type is set to |
|
Data provider |
Enter the name of the local membership provider where users are created. |
|
Title |
The text that is displayed on the login button, for example, OpenID. |
|
Auto assigned roles |
Optionally, enter the roles that are automatically assigned to users registered with the OpenID Connect provider (separated with a comma). For more information about using auto-assigned roles together with user groups, see Use external authentication providers with user groups. |
|
Link CSSclass |
Enter the CSS to be applied to the login button. |
|
Require email claim from this provider |
This option, specifies whether you want to use the email address, provided by the external provider to map external users to Sitefinity CMS users. Select this checkbox, if you want users to be able to login, only if their valid email is included in the provided claim. This checkbox sets to true or false |
- Select Enabled checkbox.
- Save your changes.
- Restart the application.
OpenIDConnect.nonce cookie and SameSite cookie attribute
The SameSite attribute of cookies prevents most browsers from sending a cookie with cross-site requests. The attribute can be set to either Strict, Lax, or None. Cookies with SameSite set to None require the Secure flag. Cookies with the Secure flag are only sent with requests going to HTTPS pages.
The cookie is not sent to any cross-site context, if the value is set to Strict. When the SameSite attribute is set to Lax, which is the default value and most browsers consider cookies without a SameSite value to be set to Lax, the cookie can be sent to cross-site context only in the headers, which means that POST requests are rejected by the browser. In Sitefinity CMS. this prevents the implementation of the OpenID Connect provider as an external authentication provider, because the implementation requires to send the OpenIDConnect.nonce cookie in a cross-site context with a POST request.
To allow the OpenIDConnect.nonce cookie to be sent with cross-site requests, Sitefinity CMS automatically changes the value of the attribute from Lax to None and sets the Secure flag to true. This, in turn, prevents development and testing under localhost or any other domains that do not use an encrypted transport layer and require the cookie to be sent in cross-site context.
You can continue to develop and test with the OpenID Connect provider set as an external authentication provider by using the Validate OpenIDConnect.nonce cookie configuration. For more information, see Validate OpenIDConnect.nonce cookie.
Map external claims to profile properties
You can create a claims map that will map claims of the external provider to the respective Sitefinity profile properties. The list defines claims to property fields mapping in the following format: Key – profile field, Value – claim name.
There are some preconfigured mappings, you can add more by performing the following:
-
Navigate to Administration » Settings » Advanced.
-
In the left pane, expand Authentication » SecurityTokenService » AuthenticationProviders.
-
Expand the OpenIDConnect and click ClaimsMap » Create new.
-
In Sitefinity field, enter the name of the property that you want to map.
To specify the profile field, you must use a combination of the profile type name and the profile field name in the following format - <profile_type_name>.<property_name>
For example, if you want to map a field called FirstName, from the default SitefinityProfile profile type, in Sitefinity field, enterSitefinityProfile.FirstName.NOTE: Custom profile fields have to be created first and then mapped. For more information, see User profiles.
-
In Claim from external provider, enter the name of the claim that you want to map to.
For example, entergiven_name. -
Save your changes.
EXAMPLE: You can also map fields from custom profile types. For example if you have created a custom profile type, called AzureInfo, and want to create a mapping for its FullName field to a claim called user_fullname, in Step 4, enter
AzureInfo.FullNameand in Step 5, enteruser_fullname