Trust is a key aspect in any security solution. The need for security is based on the premise that two parties share
some level of trust. That level can be on a continuum, from "completely trusted" (therefore, no need for security) to
"completely untrusted" (where paranoia rules).
-
No trust, also known as blind trust: The provider might be providing a public service and has no
need to trust the invoking system. The invoking system can send an identity with no proof and expect the
provider to assume the identity when processing the request. There might be no measures taken to prevent
impersonation attacks.
-
Network configuration-based trust: There is no software configuration that provides trust. The network is
configured, possibly through division into firewalled subnets, in such a way to restrict the number of machines
that could transmit a message to the provider. The degenerative case would see only the intended invoking system
and provider system on the subnet. Sometimes VPNs are used to restrict the potential invoking systems.
-
Infrastructure-based trust: The infrastructure (for example, the transport protocol, possibly MA SSL or
SSL + BA) is configured to identify the invoking system to validate that it's a trusted system. There is nothing in
the Web services (SOAP) message, other than the invoker's identity, that the provider needs to assume when
processing the request.
-
Token-based trust:
-
Point-to-point token trust. There is a token in the message that asserts an invoker's
identity, and it was provably created by a trusted invoking system (for example, Security Assertion Markup
Language, SAML, or Lightweight Third-Party Authentication, LTPA).
-
Third-party token trust. There is a token in the message that asserts an invoker identity
and which was provably created by a trusted third party system key distribution center (KDC), such
as SAML or Kerberos.
-
Token context-based trust:
-
Signature that covers the token and message. There is a signature in the message. It is
created by a trusted invoking system that covers the message and the token, thus it asserts the invoker's
identity and authenticates the invoking system.
-
Two tokens in the message. There is a token in the message that authenticates the invoking
system as a trusted system and another token that identifies the invoker. There needs to be some mechanism
to bind the two tokens together and to the message, such as a signature.
-
Authentication. This is the extreme end of trust. Any token that provides proof removes the
need for an extra mechanism to establish trust.
Trust zones
In large organizations, it is often efficient to subdivide the enterprise into administrative regions and establish
different trust zones. Between different zones, there are various subtypes of trust relationships that can be
established. These are examples of some of the ways that two parties can establish a trust relationship when only one
of the parties has a relationship with the end user:
-
Direct Trust - Token Exchange: Trust Domain 1 authenticates the end user, and Trust Domain
2 requires an identity or identifier (identity propagation). In some cases (for example, where only
personalization is required), authentication might not be needed.
-
Direct Trust - Token Validation: Trust Domain 1 might create a new assertion (an identity
assertion) offering its own proof that it has authenticated the identified user. Trust Domain 2 evaluates that this
assertion came from someone it trusts (Trust Domain 1) and uses it in place of authenticating the user itself.
-
Token Services and ISPs: Sometimes trust relationships are established among multiple
parties, and the authentication of the user is separated, as an independent service (identity service provider).
These identity service providers have various kinds of functionality. Some can look at the destination of the
request and determine whether the user has been authenticated, thus know if the current token needs to be exchanged
for a second token and can redirect this request to the appropriate parties.
-
Indirect Trust: Sometimes parties do not have a direct trust relationship, but they work
with a third party that they both trust to broker an exchange.
-
Delegation: Combinations of direct and indirect trust relationships can be established
|