Backward compatibility

Sitefinity CMS supports the following modes of authentication:

• Claims authentication with JWT (JSON web token)
  This is the default authentication model. It is implemented on top of IdentityServer3, certified by OpenID Foundation.
  For more information, see Authentication.
• Claims authentication with SWT (Simple web token)
• Forms authentication

You can change the authentication model by changing the Security settings in the Advanced Settings page. You can also edit additional settings such as UserIsOnlineTimeWindow and BackendUsersSessionTimeout in the Security page. For more information, see Settings and configurations page.

Sitefinity CMS version 4.x has been using an implementation of Forms-based authentication in order to verify a user’s identity and log them in. Sitefinity CMS supports the implementation of forms authentication for backward compatibility and for users who want to explicitly keep using it.
For more information, see Administration: Switch to forms authentication.

Forms authentication was conducted in the following way:

• Credentials of the user are sent (usually by the login form).
• Once the user was authenticated, information about the identity was stored in a cookie.
• As long as the cookie has not expired, the user was kept logged in.

The mechanism, which authenticates the user, and the procedures of storing and retrieving the information of the user’s identity in the cookie were built into Sitefinity CMS core and follow a specific proprietary implementation.

Sitefinity CMS supports the implementation of SWT for backward compatibility and for users who want to explicitly keep using it.
For more information, see Administration: Switch to Claims-based SWT authentication.

Compared to Forms, Claims-based authentication relies on a more robust mechanism of authentication, by which details about the user’s identity are encoded into a digitally signed string referred to as a token.

The token is issued once the user’s identity is determined by a dedicated service – Security Token Service (STS). The STS can run from within Sitefinity CMS, but can also run separately, and may even be a trusted third party.

The implementation of claims-based SWT authentication is based on Microsoft’s Windows Identity Foundation, which is built on top of the .NET framework.

Following is a scheme of how a token service works:

With claims-based authentication with single sign-on, once a user logs in and retrieves a valid token from the STS, the encrypted credentials are stored in the standard forms authentication cookie.

• When the user logs out and then reloads a page on the same browser, the information in the authentication cookie is automatically used for logging the user in, while issuing a new token from the STS. The effect is, as if the user has not been logged out, although this is not the case.
• If the last allowed user (according to the number of concurrent users defined in the license) is being forcefully logged out by an administrator and a new user logs in their place, the logged out user will be presented with the force logout screen with information about the logged in user.
• If the server session expires while the forms authentication cookie is still valid, the user will remain logged in, as described above. If the server session has expired and the STS forms authentication cookie has also expired – the user will be asked for credentials in order to be logged in.

• Using the IIS.
  
  1. In the sites tree, navigate to your website.
  2. Double-click Authentication.
  3. In the context menu of Forms Authentication, click Edit...
  4. In Authentication cookie time-out (in minutes) field, set the timeout.
     This is also valid when Forms Authentication is disabled on the site.
• Using the site's web.config file.
  The timeout is set in minutes in the Authentication section under <system.web>:
  

There are several immediate advantaged for using claims-based authentication:

• Since the implementation is more distributed and not based on identity data stored in a cookie, as long as the users hold on to a valid issued token they can initiate requests. Once the users need to log in again, they can immediately retrieve a new token by calling the STS, and continue their work.

• This implementation of claims-based authentication allows separation of the authentication mechanism (the token issuing service, STS) from Sitefinity’s main application (the relying party).

• Sitefinity’s claims implementation does not rely on the cookie’s lifespan. Re-authentication is fast and service-based, which allows a better flow.

• Sitefinity’s main application (the relying party) may rely on any third party token issuing service, which complies with claims-based authentication specification.

• Relying on third party tokens allows connection with external accounts – Single Sign On (SSO) such as Windows users.
• You can configure and use change password functionality. For more information, see Change password widget.

Following is a scheme of how claims-based authentication works:

• Sitefinity’s security token is based on the Simple Web Token (SWT) standard, as opposed to the heavier and more robust commonly SAML and OAUTH standards.
• The token, which is issued by the STS and kept on the client until the next need for a fresh token, is also referred to as the bootstrap token.
• The token contains the information requested by the application in different fields.
• The token is digitally signed by the STS using SHA-256 algorithm.
• Sitefinity’s STS returns the token uncompressed, unless deflate=true is present in the request parameters. In this case, the token is GZip-compressed, and deflated will be specified in the response.
• If the token is deflated, the token gets Base64 encoded.
• The token is also URL-encoded.
• If a redirect_uri parameter is present in the token request, the client is redirected to the requested URL.
  Otherwise, the token will be returned in the body of the response.

Sitefinity’s implementation of claims-based authentication complies with the Federal Information Processing Standards (FIPS).

The identity token is being digitally signed using SHA-256 hash algorithm.