For some applications, a single component-wide access control list is not sufficient. Some methods in a component may be accessible only to certain users.
Example: An accounting business component may have a method for registering new transactions and another method for retrieving existing transactions. Only members of the accounting department (user group "Accounting") should be able to add new transactions, while only members of upper management (user group "Upper Management") should be able to view the transactions.
As indicated in the previous section, applications can always implement their own security by managing their own user database and security credentials. However, working from a standardized security framework provides many benefits to end users. Without a security framework , users have to remember and manage logon credentials for each application they are using. Developers have to be aware of security in each and every component of their applications.
DCOM simplifies customizing security to the needs of specific components and applications, providing extreme flexibility while incorporating any security standard supported by Windows NT. See the following section for details.
How can an application use DCOM security to implement the selective security required in the examples above? When a method call comes in, the component asks DCOM to impersonate the client. After this, the called thread can perform only those operations on secured objects, that the client is permitted to perform. The component can then try to access a secured object, such as a registry key, that has an Access Control List on it. If this access fails, the client was not contained in the ACL, and the component rejects the method call. By choosing different registry keys according to the method that is being called, the component can provide selective security in a very easy, yet flexible and efficient way.
Figure 14 - Per interface security using registry keys
Components can also simply obtain the authenticated username of the client and use it to look up permissions or policies in their own database. This strategy employs the authentication mechanism of the Windows NT security framework (password/public key, encrypted passwords on the wire, etc.). The application does not have to worry about storing passwords or other sensitive information. The next version of Windows NT will provide an extended directory service that allows applications to store custom data inside the Windows NT user database.
DCOM provides even more flexibility. Components can require different levels of encryption and different levels of authentication, while clients can prevent components from using their credentials when impersonating. For more details on DCOM's advanced security infrastructure, see the "DCOM Architecture" White Paper.