Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

Standalone conceptSecurity conceptChapter III · Security · Building block 5 of 7

Authorization

An authenticated caller must not automatically be allowed to access every resource.

By Michael Meierhoff · Meierhoff Systems

  1. SubjectSubject: A user or service requests an action.
  2. ResourceResource: The target and its protection needs are identified.
  3. PolicyPolicy: Context determines the permitted action.

Context

Why this is important

Permit actions through explicit access rules.

Permit actions through explicit access rules.

Shop example · Mapping

Authorization: inspect the decision

The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. A support agent authenticates to the shop back office. When opening order B-1042, the service checks her support role, customer relationship, and requested action. She may read status and shipping history but cannot trigger payment again. The rule is applied server-side on every access and audited with subject, resource, and outcome. A UI toggle alone would not protect the operation.

This is how you read the picture

  1. Subject Subject
  2. Resource Resource
  3. Policy Policy
Authorization: inspect the decision
ConceptMeaningReview question
SubjectA user or service requests an action.Which action remains restricted to the customer flow?
ResourceThe target and its protection needs are identified.Which parts should an access rule name?
PolicyContext determines the permitted action.Where must the rule be enforced?
Regeln können in ACLs, Rollen oder Policies ausgedrückt werden. Sie müssen an jedem relevanten Zugriffspunkt gelten und bei Änderungen widerrufbar bleiben; ein erfolgreicher Login begründet keine pauschale Erlaubnis. Use the questions in the second column to test this scenario.

Benefits & limitations

Helps if:

  • Permit actions through explicit access rules.
  • Model each rule as subject, action, resource, and context.

Boundaries

  • Distributed access paths can hold different policy versions.
  • Resource and tenant boundaries must be checked on every API operation, including indirect object identifiers.

In practice

  1. Write the support rule using subject, action, resource, and context, explicitly distinguishing reading status from triggering payment again.
  2. Call the same order resource directly through the API with an allowed support role, a different customer association, and a forbidden action; expect server-side denial.
  3. Check audit records for subject, resource, action, and outcome, then repeat the test after a policy change across all relevant access paths.
Read the detailed explanation

Authorization decides whether an identified subject may perform a specific action on a resource under current conditions. A decision typically considers role, object, action, and context.

Rules can be expressed in ACLs, roles, or policies. They must apply at every relevant access point and remain revocable; successful login does not establish blanket permission.

The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. A support agent authenticates to the shop back office. When opening order B-1042, the service checks her support role, customer relationship, and requested action. She may read status and shipping history but cannot trigger payment again. The rule is applied server-side on every access and audited with subject, resource, and outcome. A UI toggle alone would not protect the operation. auth and authentication help compare this decision with adjacent concerns.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    Which action remains restricted to the customer flow?

    View the solution with justification

    Another payment attempt; support may only read order status.

  2. ApplyingTransferred to a new situation

    Which parts should an access rule name?

    View the solution with justification

    Subject, action, resource, and relevant context such as tenant or owner.

  3. EvaluateWeighing an alternative

    Where must the rule be enforced?

    View the solution with justification

    At every API operation that reads or changes protected state.

Explore further

These building blocks continue the thoughts of this page.

SecurityIdentity & PermissionsContext and comparisonOpening SecurityAuthenticationConceptual connectionOpening SecurityLeast PrivilegeConceptual connectionOpening

References

Continue on the learning path

Next in Security & Trust Boundaries: Authentication.

7 Building blocks

Continue withAuthentication