1. Identity Management
Identity management is the security
aspect that deals with which security identity the client sends to the
service and, in turn, what the service can do with the client’s
identity. Not only that, but when designing a service, you need to
decide in advance which identity the service will execute under. The
service can execute under its own identity; it can impersonate the
client’s identity (when applicable); or it can use a mixture of
identities, alternating in a single operation between its own identity,
the client’s identity, or even a third identity altogether. Selecting
the correct identity has drastic implications for the application’s
scalability and administration cost. In WCF, when enabled, the security identity flows down
the call chain, and each service can find out who its caller is,
regardless of the identity of the service.
2. Overall Policy
To the traditional commonplace security aspects of
authentication, authorization, transfer security, and identity
management, I would like to add one that is less technical and
conventional, but to me just as important: what is your business’s
approach, or even your personal approach, to security? That is, what is
your security policy? I believe that in the vast
majority of cases, applications simply cannot afford not to be secured.
And while security carries with it performance and throughput penalties,
these should be of no concern. Simply put, it costs to live. Paying the
security penalty is an unavoidable part of designing and administering
modern connected applications. Gone are the days when developers could
afford not to care about security and deploy applications that relied on
the ambient security of the target environment, such as physical
security provided by employee access cards or firewalls.
Since most developers cannot afford to become full-time security
experts (nor should they), the approach I advocate for overall security
policy is simple: crank security all the way up until someone complains.
If the resulting application performance and throughput are still
adequate with the maximum security level, leave it at that level. Only
if the resulting performance is inadequate should you engage in detailed
threat analysis to find out what you can trade in security in exchange
for performance. In my experience, you will rarely need to actually go
this route; most developers should never need to compromise security
this way.
The security strategies described in this chapter follow my
overall security policy. WCF’s overall approach to security is very much
aligned with my own, and I will explicitly point out the few places it
is not (and how to rectify it). With the noticeable exception of the
BasicHttpBinding, WCF is secured by
default, and even the BasicHttpBinding can easily be secured. All
other WCF bindings by default authenticate all callers to the service
and rely on transfer security.
3. Scenario-Driven Approach
Security is by far the most intricate area of WCF. The
following list shows the elements that govern security in every WCF
operation call:
Each of the items in the list may have a dozen or more
security-related properties. Obviously, there are an overwhelming number
of possible combinations and permutations. In addition, not all
combinations are allowed or supported, and not all allowed combinations
make sense or are consistent; for example, while technically possible,
it does not make sense to use a certificate for client credentials in a
homogeneous Windows intranet, much as it makes little sense to use
Windows accounts in an Internet application. The solution I chose for
this book is to focus on a few key scenarios (and slight variations of
them) that address the security needs of the majority of applications
today.
The scenarios are:
I will demonstrate how to make each of these scenarios consistent
and secure. In each scenario I will discuss how to support the security
aspects of transfer security, authentication, authorization, and
identity management. If you need an additional scenario, you can follow
my analysis approach to derive the required security aspects and settings.
