Security Implications Of Services Impersonating Callers

In my last post (Caller Impersonation for WCF Services Hosted Under IIS Appears Broken), I laid out my rationale for why I felt that the security of services impersonating a caller when hosted under IIS was broken. To be responsible, I feel it necessary to follow-up my previous assertion by noting that such a configuration is not a best-practice, even though many corporate staff developers may be tempted to secure their intranet services this way.

Allowing a service to impersonate the caller’s identity requires that the caller have a high degree of trust in the service that he or she is interacting with. Of course it’s very unusual for a user to be aware of the services their applications interact with, so this is a completely unrealistic expectation. When a service is configured to impersonate its callers, it could potentially perform clandestine operations within a network using authorizations granted to the caller’s identity without the caller being aware.

To further illuminate the security vulnerabilities of callers trusting services to impersonate their identities, it’s important to note that most services are focused on a specific area of business while application users typically have much broader and deeper sets of authorizations. A malicious service’s reach is magnified when the impersonated user’s identity happens to be trusted by other entities or business domains unrelated to the service.

Smaller organizations often take for granted that local intranet services are not doing malicious things using the caller’s identity; however, it’s likely not the best choice for security conscious intranet service writers to make. Even if you have complete trust in your own internal services, consider the potential for their unintended leveraged use by a malicious third party. In my opinion, it’s much safer for a service to act with its own identity rather than to impersonate the caller’s. Services can be run using an identity that has been granted the least privilege necessary for it to perform its functions. The “less is more” approach to security is considered a best practice, and should be followed whenever practical.

To summarize, even though I still consider caller impersonation under IIS to be defective, some may consider this to be an important security feature! Although a bug is still a bug no matter how much lipstick we slap on it, I have to agree that this particular bug might actually force better security choices to be made.