Concept: Trust Boundaries
Defining the levels and boundaries of trust between IT systems is critically important to establishing appropriate levels of system security.
Relationships
Related Elements
Main Description

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).

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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