Authentication, Authorization, and Accounting

Core concepts

Authentication establishes confidence in an identity; authorization decides what that identity may do; accounting records relevant events. Identity proofing, session establishment, policy decision, policy enforcement, entitlements, roles, groups, attributes, claims, and audit trails are related but not interchangeable.

Why it matters

A successful login does not prove an application authorization decision, and a valid session does not prove an entitlement remains appropriate. Centralized and local authentication can coexist. Audit records need identity, source, target, action, result, time, correlation data, and retention appropriate to the service.

Design and troubleshooting workflow

State the identity source, credential or factor, relying service, policy decision point, and enforcement point.
Check group, role, attribute, claim, and session-lifetime inputs separately.
Review failed authentication handling, reauthentication, step-up triggers, and audit evidence by time window.
Confirm the least-privilege decision with the application owner rather than inferring it from login success.

AAA checklist

Can operators distinguish authentication failure from authorization denial?
Are session expiry and revocation behavior documented?
Do logs identify the acting identity and enforced policy without storing secrets?
Are local fallback accounts controlled and reviewed?

Fictional example

An analyst can sign in to a reporting portal but cannot export data. Authentication succeeded; a role mapping changed during a team move. The investigation checks group synchronization, the application authorization log, and the owner-approved entitlement rather than resetting credentials.

Operational decision points

Start by identifying an authentication source, method, policy decision point, policy enforcement point, session issuer, and application owner. Keep those elements separate in the change record: a successful technical step can still leave an inappropriate authorization, unavailable dependency, or incomplete audit trail. Scope decisions to a named owner, system, time window, and evidence source.

Practical workflow

trace identity proof, policy evaluation, session issuance, entitlement lookup, enforcement, and accounting as separate events. At each stage, decide whether the observed result is sufficient to continue, needs an owner question, or requires a bounded rollback or escalation. Avoid turning an unavailable log or delayed response into proof that no activity occurred.

Evidence and review checklist

record identity identifier, source, method, target, result, policy reference, session correlation value, timestamp, and failure reason without recording credentials.
Confirm the accountable owner, expected dependency, approved exception, and next review date.
Test an ordinary permitted path and a relevant denial or expiry condition using approved accounts and non-sensitive data.
Separate service availability symptoms from identity, policy, session, and logging outcomes.

Fictional operational example

A federated user reaches an application but is denied a report export because the application role mapping has not received the expected group claim. The correct investigation checks claim delivery, authorization policy, and audit records rather than resetting the password.

Validation boundaries and failure modes

Troubleshoot in order: confirm source reachability, identify the authentication method, inspect the policy decision, verify session creation, inspect authorization inputs, then compare accounting records. Authentication failure, authorization denial, session failure, application failure, and accounting failure need different owners and evidence.

Before closing a review, confirm the result with the system owner and retain a reference to the relevant configuration, event, approval, or test. Missing evidence should create a follow-up question, not an unsupported conclusion about safety, authorization, or exposure.

Focused review checklist

Minimum log fields should make the stage visible: authentication source and method, policy decision, policy enforcement result, session identifier, entitlement or role input, application result, timestamp, and correlation reference. Cache and local fallback behavior should be documented as explicit design choices, including whether a dependency failure fails open or fails closed.