The authorization model is another new feature in the Commerce Server 2007 catalog system which allows you to protect your catalog data from being accessed by unauthorized users. Since we decided to expose the functionality of the catalog system over the web service it became imperative to ensure that only authorized users can access the catalog data. The catalog system in Commerce Server 2007 has two main components: the catalog web service and the catalog database. Both these components can be appropriately secured.
Securing the Catalog web service
First let’s talk about securing the catalog web service. Securing the catalog web service involves securing the web methods to ensure that unauthorized users cannot successfully invoke these methods. Instead of reinventing the wheel and introduce another authorization model for users to learn we decided to use the Windows Authorization Manager. There are several articles on Authorization manager on msdn. You can also check out the Authorization Manager Team Blog for overviews, case studies etc.
The catalog system provides various levels of authorization which can be defined by assigning the users to the different roles. Users can be Administrators, catalog editors, language translators etc. You can also create your own user model and still enforce the catalog authorization in the web service. The authorization model also allows you to control which users can view which catalogs and edit which properties. For eg you can disable certain users from editing specific product properties like list price, description etc.
The catalog system supports only the XML store which means that the authorization information is defined in an xml file. The name of the xml file is specified in the catalogWebService element in the web.config via the authorizationPolicyPath attribute. When you unpup the catalog webservice a default xml file named CatalogAuthorizationStore.xml is installed in the web service directory (typically <Drive>:\Inetpub\wwwroot\CatalogWebService). You can use the authorizationPolicyPath attribute to specify a different authorization store. If the specified path is not an absolute path then the path is relative to the catalog web service’s directory.
After you install the catalog web service you need to perform the following steps to get the catalog webservice up and running.
1. Application pool: Verify that the catalog web service has been assigned to the desired Application pool. Verify the properties of the application pool especially the Identity. The identity of the application pool is the name of the account under which an application pool’s worker process runs.
2. Once the identity of the catalog web service’s application pool has ben configured ensure that this account has write access on the catalog authorization store. You can do this by right clicking the CatalogAuthorizationStore.xml, click properties, select the Security tab, add the catalog web service’s account and check the Allow Write checkbox. The catalog system offers catalog level security which means that you can control which users can access which catalogs. This has been implemented by means of scopes in the authorization store. Since the catalogs are dynamically created in the catalog system it becomes necessary to create a new scope in the authorization store every time a catalog is created. Creating the catalog scope needs write permissions on the xml file. This is why you need to ensure that the account running the catalog web service has Write permissions on the catalog authorization store. If this is not done then the catalog web service will throw a configuration exception at startup and none of the methods can be invoked.
3. The final step is to add the user accounts to the appropriate roles. This can be done by the Authorization Manager MMC. To do this
- Right click Authorization Manager
- Click Open Authorization Store
- Select the CatalogAuthorizationStore.xml
- Expand CatalogAuthorizationStore->CatalogAndInventorySystem->Role Assignments
- To add a user to a role, right click the role and select “Assign Windows Users or groups” and add the users to the appropriate roles.
Note that adding the user the Administrator role will allow the user to perform any operation in the catalog system.
4. As I mentioned previously we dynamically create scopes for each catalog, language and property in the catalog system to provide a finely grained authorization mode. This means that every time you create a new catalog you need to follow the above steps to ensure that appropriate users have access to this catalog. The only difference is that you need to expand the node named “CatalogScope_<Catalog Name>”->Role Assignments and add the users to the CatalogEditor role.
5. If you are unable to access the catalog web service due to the following exception: System.IO.FileNotFoundException: File or assembly name 0x1gew0n.dll, or one of its dependencies, was not found. File name: “0x1gew0n.dll” at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Boolean isStringized, Evidence assemblySecurity, Boolean throwOnFileNotFound, Assembly locationHint, StackCrawlMark& stackMark) — LOG: Attempting download of new URL file:///C:/WINDOWS/TEMP/6hg1.dll. The resolution for this issue is to grant write permissions on the temp directory mentioned in the above URL (C:/WINDOWS/TEMP) to the catalog web service account.
The next post will be about the various operations, tasks and roles and how you can create your own tasks and roles to enforce an authorization model which is driven by your business needs. It will also discuss how to define permissions for the various user scenarios.