Direct and Brokered Authentication
When aggregating
services into compositions, new requirements emerge for authentication.
In the past, monolithic systems were able to take into account certain
assumptions about the security context from which an application was
accessed. Most times, the application owned the user credentials and
could simply validate a client’s claim by checking the supplied
credentials against a database or LDAP store.
Service-oriented solutions can
no longer rely on such assumptions. Accessing one service may result in
the invocation of multiple services, plus it can be common for a service
consumer to require access to multiple different services in order to
complete a single task. These new dynamics have introduced new security
models for authentication.
Direct Authentication
Direct Authentication
is a pattern based upon a trust relationship that exists between the
service and service consumer. This trust relationship allows the service
to accept a claim of identity directly from the service consumer and
validate this claim based on information already owned by the service.
The most common example of first
party authentication is the exchange credentials in the form of a user
ID and password. The credentials are validated against a security store
either owned by or directly accessible within the service implementation
(Figure 1).
This
approach is reminiscent of traditional authentication mechanisms used
in point-to-point data exchange, and is therefore common with single
service-consumer message exchanges.
Brokered Authentication
Brokered Authentication
is typically used in situations where a trust relationship does not
exist between a service and a potential service consumer. Instead,
separate trust relationships are established between the service and an
authentication broker, and between the service consumer and the
authentication broker. In other words, the service consumer is
responsible for establishing an identity with the authentication broker
and this same authentication broker forms a trust relationship with the
service (Figure 2).
Authentication Patterns in WCF
When
determining how to establish an authentication mechanism within WCF,
decision factors are largely dependent upon the use cases for a given
service. Considerations that can affect this decision include:
the type and location of the existing credential store used within the service inventory
the trust boundaries associated with the service
the constraints applied to authorization (explained in the next section)
These decisions should be driven more by business needs rather than technical merits.
The patterns described
so far are explained with scenarios that are primarily concerned with
uniquely identifying service consumers to the service. However, with
service-oriented solutions, authentication often refers to the mutual
authentication of the consumer and service when taken in the context of
the WCF. Mutual authentication allows the service to positively
identify the consumer trying to access it and it also enables positive
identification of the service by the service consumer.
This is specifically
relevant to WCF services that are Internet-facing. Without the ability
to verify the authenticity of a service, an attacker could spoof the
service and hijack messages. Such an attack could potentially expose
sensitive data contained in messages intended for the genuine service.
