Call Security
COM provides two mechanisms to secure calls. The first mechanism is similar to DCE-RPC: COM provides APIs that applications may use do their own security checking. The second mechanism is done automatically by the COM infrastructure. If the application provides some setup information, COM will make all the necessary checks to secure the application. This automatic mechanism does security checking for the process, not for individual objects or methods. If an application wants more fine-grained security, it performs its own checking. However, the two mechanisms are not exclusive: an application may ask COM to perform automatic security checking and then perform its own.
COM call security services are divided into three categories: general APIs called by both clients and servers, new interfaces on client proxies, and server-side APIs and call-context interfaces. The general APIs allow the automatic security mechanism to be initialized and automatic authentication services to be registered. The proxy interfaces allow the client to control the security on calls to individual interfaces. The server APIs and interfaces allow the server to retrieve security information about a call and to impersonate the caller.
In a typical scenario, the client queries the object for IClientSecurity, which is implemented locally by the remoting layer. he client uses IClientSecurity to control the security of individual interface proxies on the object prior to making a call on one of the interfaces. When a call arrives at the server, the server may call CoGetCallContext to retrieve an IServerSecurity interface. IServerSecurity allows the server to check the client's authentication and to impersonate the client, if needed. The IServerSecurity object is valid for the duration of the call. CoInitializeSecurity allows the client to establish default call security for the process, avoiding the use of IClientSecurity on individual proxies. CoInitializeSecurity and CoRegisterAuthenticationServices allow a server to register automatic authentication services for the process.
Implementations of QueryInterace must never check ACLs. COM requires that an object which supports a particular IID always return success when queried for that IID. Aside from the requirement, checking ACLs on QueryInterface does not provide any real security. If client A legally has access to interface IFoo, A can hand it directly to B without any calls back to the server. Additionally, OLE caches interface pointers and will not call QueryInterface on the server every time a client does a query.
Each time a proxy is created, COM sets the security information to default values, which are the same values used for automatic security.