Application Security Series, Conclusion
Let me summarize what I have proposed through this lengthy series of posts. We have discussed application security, which covers authentication and authorization.
Concerning authentication, your customers want your applications to become better corporate citizens. They want them to rely on user data in a global directory service, rather than adding their own proprietary repository of that data to the enterprise. However,
· enterprises sometimes have more than one directory service,
· network administrators typically do not permit changes to the schema of a directory service to accommodate the specific data that application needs to have concerning its users, and
· a lot of organizations, especially smaller ones, do not have any directory service at all, so having one’s application depend on a directory service that may not exist seems unwise.
The answer to those problems begins with storing the application’s user data in AD/AM. If the organization implements MIIS, then it can be used to synchronize data in the organization’s directory services with AD/AM. If the organization does not implement MIIS, or has no directory services, then AD/AM will be populated with user data manually or programmatically, just as user data would have been entered into the application’s database.
· we would like to be able to define abstract operations for which we would want to control authorization, abstract operations that we could map to elements of our user interface
· we would like to be able to compose those operations into coarser-grained tasks so that we could permit or deny whole sets of operations at once by permitting or denying the task
· we would like to organize the users of our application into roles defined specifically for our application, and then permit or deny each group to perform each task.
· we would like to be able to do all of this through a user interface
As we have seen, the Windows 2003 Authorization Manager provides for all of these requirements.