Several people have asked me how to customize security in AC7. So in an effort to avoid the work I SHOULD be doing, this seemed like the perfect time to write an article This article describes how to create customized security roles in AC7. These will be different and in addition to the existing roles provided by the default install. As always, back up anything you're going to change before you change it. Some (very) minor programming will be involved and you'll need direct access to your store SQL tables.
Security Roles Explained
ASP.Net Security roles are the result of three different ASP.Net security features coming together.
First, every folder in the Admin side has a web.config file. This file dictates, among other things, which security roles have access to the contents of the folder. You can specify groups and/or specific users to be permitted(allow) or prevented (deny) access to the folder contents.
Second, the standard sitemap file in the ~/Admin/ folder dictates what menu options are available and presented to the user on the Admin side. Users that are not a member of a particular security role will never see the menu options assigned to that role. Note that these permissions are separate from the web.config settings – someone can be denied permission to see a menu option yet still have permission to hit the sub-folder URL directly.
Third, authentication data provided via the ac_Users, ac_UserPasswords, ac_Roles, ac_UserGroups and the ac_Groups tables. These tables store the actual user account information used to authenticate to the site as well as define group membership, etc.
A fourth method, not part of the default .Net security setup, is a few custom classes and methods written by Able to assist with security in programming code.
Defining the New Role
The first step in any customized security role is identifying the specific permissions you require. In our case, we're going to make a "Warehouse Manager" or WM for short. This WM will have access to certain menu options, but not all of them.
So to begin, we have to sit down and make a list of precisely what menu options we want our new WH role to see. That seems like a lot of work, and it is. But it’s very important for a number of reasons. First, it makes you precise and security is a really good place to be precise. Second, it brings to your attention exactly what will/won’t be available to members of the new security role. This helps a great deal in getting things right the first time thus reducing the deployment time of new security roles. Finally, it is good documentation that can keep your behind out of hot water down the road should a security issue within your organization arise.
Fortunately for you, I’ve made this job much simpler for you. Attached to this post is an Excel spreadsheet detailing every existing Admin menu. This spreadsheet also gives you a complete breakdown of every default AC7 security role and what permissions are involved with that role. A spreadsheet like this comes in very handy when you want to build entirely new security roles.
Now with your trusty spreadsheet loaded up, just start a new column to the right of existing roles called “Warehouse Manager”. Beneath that new column, mark the permissions you want. Not only does this give you that great documentation we talked about earlier, it also helps you be sure of exactly what the users in that role will have access to use.
Create a new AC7 Role
Able didn’t include a fancy menu option or edit screen to create new roles. So, we’re going to add one manually. You’ll need direct access to your SQL database to complete this step.
To add a new role definition, expand your store database within SQL Server Studio Express and scroll down to the ac_Roles table. Right click the table and choose Open Table. This will let you see all the existing roles in a nice table layout. You’ll notice the very bottom row has an asterisk (*) in it and Null for all the values. That row is where we can add new records.
Move your cursor down to that asterisk row by clicking the mouse in the Name column of that row. The Null will disappear and your cursor will let you type. Go ahead and type the name of the Role you want to define, in our case “Warehouse Managers” will do quite nicely. Move over to the LoweredName column and enter the same name in all lower case i.e. “warehouse managers”. Be sure to leave the RoleId column set to Null – the system will automatically assign the next available Id value.
You’ve just created a new role – you can see this role during the next step. For now, close out of SQL Express and get ready to log back into your website Admin side.
Assigning a Group to the Role
Able doesn’t give you a way to make new roles, but you can make new Groups. And even better, these groups can be assigned to a specific Role. So we’re going to do just that for our WM role.
Log back into the Admin side and go to People/User Groups. On the right side in the Add Group section, type in “Warehouse Managers” and select the Warehouse Managers choice in the permissions list. Wait a minute – that’s our new security role!
Now that you have a security group assigned to this role, the final step is to assign users to the group. That’s easy enough to do so we’re not going to explain it here. However you want, get your new WM users assigned to the new WM group.
Modifying Folder Permissions
Now for the completely un-fun part. Remember all those menu options you selected in the Excel spreadsheet. Well each of them is stored underneath a specific folder in the /Admin/ folder of your website. These folders are named very closely to the menu options that correspond to them. People is in the /Admin/People folder. And People/Users is in the /Admin/People/Users folder. Not every single menu option is set up this way, but most are.
The reason is ASP.Net permissions are broken down by folder. So if you wanted to keep things flexible, you put different pages inside different folders and let the web.config file decide who can see them. In the case of AC7, we can let some people manage users while preventing them from managing user groups because the respective pages are kept in completely different folders. Since each folder has a separate web.config file, the permissions are managed separately.
Swell you might say, but how do I give my new WM role access to these folders? Simple: Edit the web.config file in each folder you want the WM role to be able to access. If you get confused or are unsure where a particular menu option pages are stored, look it up in the /Admin/menu.sitemap file to see the path.
Within each web.config file you’ll see a line like this:
Code: Select all
<allow roles=”System,Admin,Jr. Admin” />
Code: Select all
<allow roles=”System,Admin,Jr. Admin,Warehouse Managers” />
Assigning Roles to Menu Options
Last but not least, we need to let our WM users see menu options. Currently the WM role is not assigned to any menu choices, so a WM user who have no menu to see.
Edit the /Admin/menu.sitemap file with a text editor such as Notepad. Right away you’ll notice that all the major menu choices like “People”,”Catalog”,”Marketing” etc have a roles= parameter like this:
Code: Select all
<siteMapNode title="Marketing" LookId="TopItemLook" roles="System,Admin,Jr. Admin">
Code: Select all
<siteMapNode title="Marketing" LookId="TopItemLook" roles="System,Admin,Jr. Admin,Warehouse Managers">
Dashboard Sections
Perhaps by now you've noticed something odd about the dashboard while logged in under your new security role. The Dashboard is gone - poof - nada - zilch - not there any more. That's because the Dashboard plug ins are all hard-coded for specific user permissions. If the logged in user does not belong to the hard-coded group, the dashboard control doesn't render.
This is easily fixed by modifying the code. First, find the dashboard control you want modified in the /Admin/Dashboard folder. Edit it's .ascx.cs code file with a text editor such as Notepad. Near the beginning of the code file you'll see a line like this:
Code: Select all
if (Token.Instance.User.IsInRole(CommerceBuilder.Users.Role.ReportAdminRoles))
Code: Select all
if (Token.Instance.User.IsInRole(CommerceBuilder.Users.Role.ReportAdminRoles) | Token.Instance.User.IsInRole("Warehouse Managers"))
Conclusion
So was this more work than you thought it was going to be? Oh yeah. But with a little planning and some persistence, you've added a completely new security role to your AbleCommerce 7 install. You've also improved company security by ensuring only the necessary people see key information about your online store.
As always, never attempt changes to your website without a solid backup available. Some things can be broken in such a way that the whole site goes down. That means it's best to practice these changes on a development install or at least during an off-peak period of time for your store.