Software Architecture / Interactions: distribution, failure, and operation / Lesson 11

Design trust and authorization at every boundary

Connect data flows, identity, resource authorization, secrets, and safe audit evidence in the workshop system.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish authentication from authorization and network location from trust.
Describe abuse cases and controls without executing attacks or using credentials.

Map what must be protected and from whom

Begin with assets and actions: learner contact details, workshop administration, reservation ownership, and capacity changes. A trust boundary occurs when data or authority crosses between contexts with different assumptions, such as a browser and an API or an application and an external mail provider. A private network does not make every request trustworthy. Record which identity is established, how its claims are validated, and which component decides permission for the target resource. Threat modeling is a structured design conversation, not an instruction to attack a live system.

Authorize the action on the requested resource

Authentication establishes an identity under a chosen mechanism; authorization decides what that identity may do. A learner who can read one reservation must not gain access to another by changing its identifier. Apply permission checks at the server-side owner of the operation, including background and alternate API paths. Deny by default and handle policy evaluation failures safely. The offline model below checks an invented ownership rule only. It does not validate tokens, sessions, delegated roles, or enterprise identity policy and should not be presented as a complete access-control system.

python An isolated ownership-policy model

def may_read_reservation(actor, reservation):
    return actor is not None and actor == reservation["owner"]

record = {"id": "r-7", "owner": "learner-A"}
for actor in ["learner-A", "learner-B", None]:
    print(may_read_reservation(actor, record))

Expected output

True
False
False

Only learner-A passes the declared ownership rule; another identity and an absent identity fail. All records are synthetic, and no account or service is queried.

Validate data where it enters a responsibility

Client-side validation improves feedback but cannot replace server-side checks. Validate syntax, size, range, and business meaning before using input in a sensitive operation. Parameterized database access addresses one injection boundary but does not authorize a reservation or prevent an oversized export. Avoid passing untrusted external fields straight into internal domain objects that imply stronger guarantees. An adapter can translate provider-specific data into a validated internal representation, including an explicit failure path when required facts are absent or contradictory.

Minimize the authority and exposure of integrations

A notification component should receive only the data and permissions required to deliver the intended message. Keep provider secrets outside source examples and logs, and use the environment’s approved secret delivery and rotation mechanisms. A service identity needs restricted scope and lifecycle ownership; sharing one powerful credential across all components expands the consequence of compromise. The sample data-flow note uses no credential and makes retention an explicit decision. Technical controls must match the actual deployment and data-handling obligations rather than an invented universal policy.

yaml A data-minimization boundary note

flow: booking application to notification adapter
required_fields: [reservation_id, destination, template_id]
excluded_fields: [session_token, full_profile, payment_details]
authority: send approved notification templates only
retention: defined by the data owner and applicable policy

Field names illustrate a design review. The note does not configure a provider or establish compliance; implementation must enforce the selected data and authority limits.

Record useful security evidence without leaking the asset

Audit records should connect an actor, authorized action, resource reference, time, and outcome at an appropriate sensitivity level. Avoid raw tokens, passwords, unnecessary contact details, or entire request bodies. Protect the audit path against unauthorized modification and define access and retention ownership. Design negative tests for missing identity, wrong owner, expired authority, and policy failure in an isolated test environment. This lesson runs only a pure ownership function; no live authorization probing, scanning, token handling, or security certification is performed.

Common errors and fixes

A hidden UI button is the only permission check.

Why it happens: Presentation behavior was mistaken for a server security boundary.
How to fix it: Enforce resource authorization at every server-side entry path.
Prevent it next time: Test direct API calls against the policy in an isolated fixture.

Internal requests bypass authorization entirely.

Why it happens: Network location was treated as proof of authority.
How to fix it: Establish service identity and explicit operation permissions.
Prevent it next time: Include internal flows in the trust-boundary map.

Logs contain session tokens and full profiles.

Why it happens: Debug convenience overrode data minimization.
How to fix it: Remove sensitive fields through the approved process and log safe references.
Prevent it next time: Review telemetry schemas as data interfaces.

Check your understanding

1. Does an unpredictable reservation identifier replace ownership checks?

Show worked solution

No. Identifiers can leak through links, logs, or ordinary sharing. The server must authorize the authenticated actor for the requested reservation and action. Unpredictability can reduce guessing but does not establish permission. Include a negative test using a known identifier owned by a different synthetic learner.

2. A mail adapter requests a full learner profile for one confirmation. What should change?