Harbor Access / 03 / PRACTICE GUIDE

Authorization, group inheritance and separation of duties

Explain who can perform which action on a resource in the local access desk. Make nested groups, expiry and explicit denies visible.

Download guide and workpapers

Original AI-assisted SecNet educational content; examples are fictional. Not a source organization publication or endorsement. Sources checked: 2026-10-21.

Local access decision desk

Use synthetic data only. Text is neither transmitted nor saved to an account. Include no real tokens, passwords or personal data.

Teaching profile: exact resource/action match, nested groups, fixed UTC request time, expiry and explicit-deny precedence. Review references are unverified assertions. One membership witness path is shown. No real sign-in, JWT/signature, MFA, device, session or provider permission is validated. Separation of duties is not computed.

EVIDENCE REVIEW DESK

Move from observations to decisions.

Code here is a local policy model with no target connection. Passing model cases are not security approval or device tests.

Signed in: allow the object? / Incomplete decision

Inspect an incomplete decision based on record existence or another positive signal. Consider denial cases alongside permitted use.

s => s.signedIn === true

Successful sign-in establishes no resource/action permission. Assess subject, object and operation scope on the server rather than relying on button visibility as a security control.

Choices and outputs last only on this open page; they do not update account progress, career status, points or certificates.

01 / EXPLANATION

Signing in is not permission to act

Authentication concerns the signed-in identity; authorization separately decides an action on a particular resource. A Harbor user may read an invoice but lack permission to change a supplier account. Servers must assess the object and operation at relevant request boundaries. Hiding a button supplies no security boundary. Tenant and ownership context also matter in real systems. The local exercise supports only exact synthetic resources and read/write/admin actions. It is not a production authorization library and deliberately omits provider-specific policy semantics and broader business conditions.

02 / EXPLANATION

Direct and indirect access

Ada may have no direct role yet receive access because her team belongs to a broader group. Show the membership chain, assignment ID and role actions together. A group name is not evidence of membership. The local desk actually expands nested memberships and rejects cycles rather than producing a misleading result. Where several paths exist, the shown chain is one witness, not an enumeration of every membership route. Real directories differ in nested-group support and role inheritance; this model claims no equivalence to any provider’s authorization behavior.

03 / EXPLANATION

Expiry and explicit-deny precedence

In this teaching profile, candidates require an active subject, exact resource/action match, expiry later than the explicit request time and a review reference. A matching explicit deny overrides candidate grants. This chosen educational rule is not a universal IAM standard. A review reference is a supplied assertion, not verified approval. Time comparisons use the fixed UTC request time, not the computer’s present clock, so the same file yields repeatable results in the downloadable CLI and browser. An admin action does not implicitly include read or write; actions must be listed explicitly.

04 / EXPLANATION

Separation of duties and exceptions

Allowing one person to request and approve the same transaction can create a conflict. A technical role list does not automatically explain every business-process conflict. Process owners define incompatible actions and who can review exceptions. Harbor workpapers request independent approval, compensation, scope and expiry. The local desk does not compute separation-of-duties conflicts; that remains a separate business assessment. An allow result reflects narrow rules, not a judgment that a person or organization is trustworthy. Learners should explain the result through specific assignment and deny IDs.

Build the evidence yourself.

Blank workpapers are not completed tests. Fill them in your authorized environment without secrets or real personal data.

Identity and access scopeMarkdown · ENPermission and negative-test planMarkdown · ENDecision, grant and evidence gapMarkdown · ENEnforcement and outcome verificationMarkdown · EN
Full guide with code, outputs and reasoning ↓

Primary references

Explanations are authored by SecNet. References support method and platform context; verify current editions and organizational policy for real use.