Authorizing live site actions via roles

After you integrate Xperience membership into your live site project and set up authentication, you can use roles to restrict access to your site’s functionality or content.

Restricting access to site content using roles

Add the Authorizeattribute to your controller classes or action methods. Set the attribute’s Roles property and identify the required Xperience roles using their Role name (not the display name).

Example




        // Allows the "RestrictedPage" action only for signed in users who belong to the "KenticoRole" role
        [Authorize(Roles = "KenticoRole")]
        public ActionResult RestrictedPage()
        {
            return View();
        }

The standard framework behavior applies if an unauthorized user tries to access an action or controller – the application returns a 401 Unauthorized HTTP status code, causing a redirect to your site’s sign-in page if one is configured.

When determining whether a user is a member of an Xperience role, the following conditions apply:

The role must be assigned to the user for the given site or as a global role. Roles assigned for other sites in the Xperience system are not recognized.
Xperience matches sites to live site applications based on the Presentation URL set for sites in the Sites application.
Roles limited by the Valid to setting are not recognized by live site applications after their expiration date.
Roles assigned indirectly through memberships are also valid and recognized.

Note

When user’s roles are modified in Xperience, the changes apply only after the user signs out and in again on the live site.
The Authorize attribute does NOT reflect Xperience permission settings for roles (for example page-level permissions). The only relevant factor is whether a user belongs to the specified roles.
The Privilege level set for users in Xperience does NOT affect the Authorize attribute on the live site.

Restricting access to entire sites using authorization

If you wish to enforce authorization over the entire MVC site (e.g., for Intranet purposes), you need to implement the authorization pipeline in a way that does not conflict with internal system logic. Otherwise, you may encounter issues with both page and form builder functionality and other Xperience features.

Use the following approach:

Create a base controller class that inherits from System.Web.Mvc.Controller and decorate it with the Authorize attribute. In the attribute’s Roles parameter, specify the roles that should have access to the restricted content.
```
 [Authorize(Roles = "IntranetUser")]
 public class BaseController : Controller
 {

 }


 
```
Derive all custom controllers used on your site from this base controller. This secures your website and ensures no internal Xperience logic gets disrupted.
```
 public class HomeController : BaseController
 {   
 }


 
```
You can allow access for users in different roles by placing additional Authorize attributes over the derived controllers. Authorize attributes placed over the derived controllers override the one inherited from the base controller. Use this approach to, for example, open sections of the site only to users in certain roles.
[Authorize(Roles = "IntranetAdministrator")] public class AccountsOverviewController : BaseController

Visiting any portion of the site now prompts users for their authentication credentials. If they do not meet the authorization criteria, they are prevented from accessing the secured content.

To allow anonymous users access to sections of the site (landing pages, etc.), decorate the corresponding controller or action with the AllowAnonymous attribute.

If you wish to enforce authorization over the entire live site (e.g., for Intranet purposes), you need to implement the authorization pipeline in a way that does not conflict with internal system logic. Otherwise, you may encounter issues with both page and form builder functionality and other Xperience features.

Use the following approach:

Create a base controller class that inherits from Microsoft.AspNetCore.Mvc.Controller and decorate it with the Authorize attribute. In the attribute’s Roles parameter, specify the roles that should have access to the restricted content.
```
 [Authorize(Roles = "IntranetUser")]
 public class BaseController : Controller
 {

 }


 
```
Multiple authentication schemes
By default, the Xperience membership integration uses a single authentication scheme (cookie authentication). If your site contains other, custom authentication schemes (e.g., JWT), you need to specify which authentication scheme to use when obtaining user details during authorization. For this purpose, use the AuthenticaitonSchemes property of the Authorize attribute:
Configuring authorization with multiple authentication schemes present
// Allows the "RestrictedPage" action only for signed in users who belong to the "KenticoRole" role // Specifies JWT as the scheme to use when verifying user credentials [Authorize(Roles = "KenticoRole", AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)] public IActionResult RestrictedPage() { return View(); }
Derive all custom controllers used on your site from this base controller. This secures your website and ensures no internal Xperience logic gets disrupted.
```
 public class HomeController : BaseController
 {   
 }


 
```
You can allow access for users in different roles by placing additional Authorize attributes over the derived controllers. Authorize attributes placed over the derived controllers override the one inherited from the base controller. Use this approach to, for example, open sections of the site only to users in certain roles.
[Authorize(Roles = "IntranetAdministrator")] public class AccountsOverviewController : BaseController

Visiting any page of the site now prompts users to authenticate. If they do not meet the authorization criteria, they are prevented from accessing the secured content.

To allow anonymous users access to sections of the site (landing pages, etc.), decorate the corresponding controller or action with the AllowAnonymous attribute.