Restrict access to Sitecore admin pages by customising the CheckSecurity method

Based on an old StackExchange query and a recent conversation, I decided to build Role-based security for Sitecore Admin pages. So, here is the blog article and associated Github code. Now, someone can use this as solution or as framework to build their own custom solution.

1. It is common knowledge that you can disable a config file by adding the .disabled suffix and even .aspx pages can be disabled by suffixing with .disabled as per this link.

2. You can completely disable or enable a few admin pages by adding the .disabled or .enabled file in the admin folder as covered in this blog. The .enabled and .disabled file is applicable only for pages inheriting from NonSecurePage like SqlShell.aspx or PowerShell.aspx.

3. Then, there are a few admin pages accessible to non-administrators too like the following, in other words, they don't pop-up the Sitecore login page if you have the developer role assigned to your user profile:

- cache.aspx 

- DBCleanup.aspx

- RawSearch.aspx

- Stats.aspx

- EventQueueStats.aspx

- logs.aspx

- PublishQueueStats.aspx

Inbuilt or Default Access:


If you are one of those purists who thinks admin pages must not be accessible to anyone other than admins then, here are a few ways to handle the situation:

I've just used one of the pages as example but the approach is same for all the above pages and in the Github code I have customised all such pages for Sitecore 10.3:

In each of these pages, there is a call to CheckSecurity as follows:


This method is part of AdminPage class and does the job of checking if the logged-in user is of role developer or the user is administrator and if they are one of the two, doesn't pop the login page:


Option-1:

Just administrator user access:




Now, create your own implementation of AdminPage class and exclude the developer check:



The original class, for example, CacheAdmin for cache.aspx will inherit from the new AdminPage as follows:


Add the new namespace/class to the .aspx page:


Rectify the original calls as need-be:

CheckSecurity()


Deploy the page and library to your website instance.

So, only administrators can access the above page. 

With this approach, you can stick-in your own set of roles/rules to the CheckSecurity method and restrict access as needed.

Page

Class

Cache.aspx

Cacheadmin

Logs.aspx

Logs

DBCleanup.aspx

DBCleanUp

RawSearch.aspx

RawSearch

Stats.aspx

stats

EventQueueStats.aspx

EventQueueStats

PublishQueueStats.aspx

PublishQueueStats

Jobs.aspx

Jobs


 Github

Disadvantages:

- Users apart from administrator cannot access

- Not fine-grained or no Role Based Access Control (RBAC)

Option-2:

Admin Page Access with a Custom role:

This approach would be to create a role just for this purpose and then override the CheckSecurity method as follows. For this example, I created a role named AdminPageAccess. through Role Manager:


Create a user with access to the above role:


AdminPage CheckSecurity method looks like this in this case:

////////////

 protected void CheckSecurity(string rolename)
        {
            if (Sitecore.Context.User.IsAdministrator || (!string.IsNullOrWhiteSpace(rolename) && Sitecore.Context.User.IsInRole(Role.FromName(rolename))))
                return;
            SiteContext site = Sitecore.Context.Site;
            if (site == null)
                return;
            this.Response.Redirect(site.LoginPage + "?returnUrl=" + HttpUtility.UrlEncode(this.Request.Url.PathAndQuery));
        }

////////////

Now, just pass the "AdminPageAccess" role name from the page' class that needs access:






So, the concerned user will have access only to jobs.aspx (in the above case) and not other pages since the attached class' cs file for other pages will have a call like this:

CheckSecurity(string.Empty);

Advantages:

- Role Based Access
- Can be assigned to different types of users

Disadvantages:

- Not fine-grained since only one role for all pages

Option-3:

The other variation would be to create separate roles and pass that role name from the respective page as follows:



Page

Custom Role

Jobs.aspx

JobsPageAccess

Logs.aspx

LogsPageAccess

DbCleanup.aspx

DbClieanupPageAccess

Stats.aspx

StatsPageAccess

EventQueueStats.aspx

EventQueueStatsPageAccess

PublishQueueStats.aspx

PublishQueueStatsPageAccess

Cache.aspx

CachePageAccess

RawSearch.aspx

RawSearchPageAccess

 
So, the CheckSecurity call in Cache class will be like this:

CheckSecurity("CachePageAccess");

Since the Sitecore user will be assigned the CachePageAccess role, the concerned user will have access to that page. So, each user can have access to different set of pages based on  their role assignment.

The developer role can now be assigned all the above roles and thus be equivalent of the inbuilt option too.


Advantages:

- Fine-grained access
- Different users can have different roles
- Role composability

Disadvantages:

- Too many roles to assign/handle

This way, you can implement fine-grained access to admin pages by creating a custom role and attaching users to such a custom role since the admin page class file will allow only that new custom role apart from administrator to access the page. This is a better approach than the hard-coded developer role in current  Sitecore Content Administration page.


Comments