Using COM+ applications for authentication and authorization
Application security comes in many flavors; the two that most concern Web applications are authentication and authorization. Authentication is the most frequently discussed security topic. By definition, when you authenticate an item of any kind, you verify that the item is what it claims to be. For example, a Web application might need to authenticate the application's users and make sure that the users are who they say they are. To authenticate a user, you typically ask the user for a username and password.
In Web application security, authorization is second in importance only to authentication. When you authorize an action, you grant a capability to someone or something. For example, after you authenticate a user, you might want to ensure that the user can access the application's resources before the user needs those resources. Now, Web application security becomes more interesting. By nature, authorization is more granular than authentication. During a session, you usually authenticate a particular user only once, but you might authorize a user more than once and in several different places within the application (e.g., in NTFS and in SQL Server).
How you provide authentication and authorization services in Web applications depends on several things. You can use Windows authentication to perform the authentication services for you, then use Windows authorization services to handle authorization. For example, after a user logs on with a valid account, you can use that account to authorize the user in NTFS, COM+, SQL Server, and other areas.
If users access your application through a firewall, you might need to use Basic authentication, which provides a valid Windows user account for the user. Basic authentication is especially handy for SQL Server, in which you can use Windows Integrated Security to authenticate user accounts that Windows 2000 (or Windows NT) has already authenticated. You can also map user account groups to SQL Server roles, providing both an authentication and authorization scheme. (For more information about security for components, see the sidebar "Component Security Terms.")
If your application uses a non-Windows account for authentication, you can't use that account for authorization. For example, if you have an extranet that has thousands of users and your IT department doesn't want to put those users in a domain or Active Directory (AD), you won't be able to use Windows accounts for the extranet users. You might decide to use your own login scheme, perhaps by creating a database (or other repository) of usernames and passwords. Then, you would validate your users against that login database or repository.
However, if you choose such an independent login scheme, you need to provide your own authorization services also. This approach works well if, in your code, you provide authorization to specific parts of the application. When you must authorize user access to specific OS features such as files, a database, an application server, or components that run in COM+ (aka Component Services), this approach becomes more difficult.
Security and Components
Today, developers are building more and more Web applications that use components to perform part of the work. My own informal research shows a sharp upswing in the number of developers who have used components in their applications over the past 2 years. Microsoft's research indicates much the same thing. Most component development involves creating components that process business rules and other components that handle data access.
This increasing use of components leads to the questions: Why, when, and how should you add security to any of these components? If you use Microsoft technologies, you have only two basic options in component-level security. First, if your application uses Windows account authentication (i.e., Basic or Windows Integrated security in Microsoft IIS) and your components run in COM+, you can use COM+ security features. Second, if your application has its own security scheme and relies to some extent on Win2K or NT user accounts, you can't use only COM+ security.
So, if your application runs in COM+, you can use either COM+ security or Windows security (e.g., NTFS) to control authentication and authorization within your components. This option eliminates a lot of the work required to establish security because you can rely on COM+ to take care of security for you. However, if your application doesn't use Windows authentication and doesn't run its components in COM+, you must handle security in another way. Let's look first at using COM+ security.