COM & .NET Component Services

Securing a Library Application

A library application is hosted in its client process. As such, it has no control over the hosting application identity and security settings. It runs under the identity of the hosting process (the Identity tab is still present in the application’s properties page, but it is grayed out and ignored). Thus, the library application has only as much privilege as the hosting client does. This limitation may be significant because the library could be loaded by many different clients and may not always have sufficient credentials to do its work. As a rule of thumb, put your meaningful business logic processing components in a server application, where you can configure exactly the application security identity. Deploy a library application in situations when you expect very a intensive calling pattern from your clients and when you can filter or process the calls before forwarding them to the server application, where the real work should take place. Another identity-related limitation is that a library application cannot declare an impersonation level, so it normally uses the process-wide impersonation level. The library application can set a desired authentication and impersonation level programmatically, as described in Section 7.8 later in the chapter.

A library application has no control over the process-level security settings, and the only way for it to perform its own security access checks is to employ component-level role-based security (role-based ...