Application Security, Part 25

So much for the user authentication requirements of application security; what about user authorization?   Most applications have user interfaces with menus, button bars and buttons and we often want to restrict users' access to those operations based on who they are. In my application, the File Menu permits users to Create New Project Tasks, and to Export to Microsoft Project and Excel, while the Manage Menu permits the user to create new projects. There is also a button bar, and the leftmost button on the bar, like the first item of the file menu, permits users to Create New Tasks. So, let us consider how we might like to restrict users’ access to these operations. Let us say that we envisage some users as being project managers, and that they alone will be entitled to create new tasks, exchange data with project, and create new projects. The main users of our application will of course be project team members who will use the application to update the status of tasks. A final group would be users who would be permitted to view the status of tasks, but not update them.

With that simple authorization scheme in mind, we turn to the tool that should provide us with a means of implementing it: the Windows Server 2003 Authorization Manager. The user interface for Authorization Manager is a Management Console snap-in. Once we have accessed the snap-in, our first task must be to create an authorization store, which will be where one’s work with Authorization Manager will be stored. To create an authorization Store, one must first opt to run Authorization Manager in Developer Mode. Then one has the option of creating an authorization store in Active Directory or in XML. When using the Active Directory store, Authorization Manager creates Active Directory objects for the store itself and child objects for each application group, application, operation, task, role and scope. For the XML option, the XML file containing the authorization store must be stored on an NTFS file system so that it can be protected by an Access Control List. To support the renaming of objects, the XML file contains globally unique identifiers that make manual editing of the XML file non-trivial and prone to error, so one should avoid doing that, and to use the Management Console snap-in or the Authorization Manager programming interface.