Securing Intranet Services
Internal applications that run on an intranet and share the same Windows domain as the services they invoke can usually take advantage of a compact binary protocol like TCP for distributed communications. In a classic client-server scenario involving distributed intranet services, the following security settings may apply:
The service will be self-hosted in a Windows service or hosted in the Windows Activation Service (WAS) for TCP access.
Windows credentials are used for mutual authentication.
Client credentials are authenticated and authorized against the Windows domain using Windows membership and role providers.
Messages are encrypted and signed at the transport layer.
The service implements role-based permission demands for protected operations.
The service applies a trusted subsystem model instead of impersonating Windows accounts.
Figure 7-4 illustrates this scenario.
Figure 7-4. Intranet clients on the same Windows domain can rely on TCP protocol and use Windows credentials for mutual authentication and message protection
This section will focus on the intranet application scenario and explain security concepts specific to that scenario. You’ll complete a lab implementing many of these concepts, and then I’ll discuss the following in greater detail:
Security features of
NetNamedPipeBindingandNetTcpBindingWindows role-based security
Client and server identities ...
Get Learning WCF now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
