Identity, Authorization, Privacy and Key Management

Digital identity is not a single feature called 'login.' Identity proofing concerns the confidence that an applicant is associated with an asserted identity, authentication concerns the present claimant's ability to demonstrate control of an accepted authenticator, and authorization determines what a proven account may do. Federation transmits an assertion across a trust boundary so that one service can rely on an identity provider. These functions may occur in the same user experience, but their evidence and failure modes are different. A student who can sign in with a known password has authenticated against the service's policy; that action does not prove every demographic detail of their account was independently verified. Similarly, a strong authenticator is not evidence that an administrator approved the correct account role.

Authentication factors are often categorized as knowledge, possession, and inherence, but security analysis must go further than naming two categories. A password plus a code delivered through a compromised device may be weaker than two truly independent protections. Phishing-resistant cryptographic authenticators can bind assertions to the genuine service identity, reducing reliance on a human recognizing a convincing imitation. Recovery mechanisms frequently become the least protected route into an account. A service that demands a robust authenticator during ordinary login but resets the entire account after a weak helpdesk conversation has a high-assurance facade and a low-assurance recovery path. Designers should inventory enrollment, initial authentication, replacement, loss, recovery, and emergency access as one lifecycle.

NIST SP 800-63-4 separates identity proofing, authentication, and federation guidance and defines assurance concepts for particular use contexts. It should be treated as a normative reference only where the organization's requirements call for it, not as a universal statement that every educational website must collect government-issued identity evidence. Proofing more personal information than the service needs can create privacy and security harm. For a low-risk public forum, a pseudonymous account may be sufficient; for official academic transcript issuance, identity binding and integrity of institutional records can justify stronger controls. The threat model, legal environment, and consequences of a mistaken identity should determine the level and kind of assurance sought.

Passwords require careful handling throughout their lifecycle. They should be stored through a suitable slow password hashing scheme with independent salt values and modern, reviewed configuration rather than reversible encryption or fast general-purpose hashes. Rate limits, detection of unusual authentication behavior, and breach-response processes supplement storage protection. Neither elaborate password composition puzzles nor excessively frequent forced changes can substitute for strong authenticators and effective compromise detection. Password managers help users maintain distinct secrets across sites. Yet a password-manager recommendation alone is not sufficient if account recovery is poorly designed or sessions remain valid indefinitely after suspected compromise.

An authentication service should not reveal unnecessary differences between 'user does not exist' and 'password wrong' when that information would facilitate account enumeration. This does not mean all login failures need identical internal diagnostics; defenders still require meaningful server-side logs to diagnose misconfigurations and abuse. Rate limits must account for shared networks, accessibility, and legitimate high-volume periods such as admission week. Locking accounts aggressively after a small number of failures can convert bad login attempts into a denial-of-service against real students. Progressive delays, risk-sensitive reauthentication, and human-support workflows deserve testing under adversarial and legitimate usage scenarios.

Federated login moves but does not remove trust. An application relying on an external identity provider must validate the issuer, audience, expiry, intended client, signature, and relevant transaction context of identity assertions. It also needs stable semantics for names and account identifiers: a display name is not a durable unique authorization key, and an email address can change owners or be reassigned. Federation often simplifies central offboarding but creates operational dependency. The application should define what happens when the provider is temporarily unavailable, how sessions expire, and how revocation propagates. In high-risk systems, local cached sessions may need shorter lifetimes or prompt rechecks after privileged role changes.

Design case. A research library supports public browsing, registered contributions, and restricted grant-review access. Public reading needs no real-name proofing. Registered contributors verify account control through an authenticator and accept a clear content-submission policy. Grant reviewers receive membership from an authorized administrative process and must use a higher-assurance authenticator. Importantly, their reviewer role is not inferred from the email domain alone. Review privileges end when the assignment expires. Recovery of a reviewer account requires stronger evidence and explicit revocation of suspect sessions. The result is a differentiated identity design rather than an indiscriminate requirement for every visitor to provide sensitive documents.

Access control is the answer to a contextual question: may subject S perform action A on resource R under conditions C? The most important engineering property is complete mediation: the decision is enforced on all relevant paths where a protected action is performed. A user interface that hides a forbidden button does not mediate a direct API call, a scheduled job, or an alternate export route. Authorization therefore belongs in trustworthy backend or data-layer enforcement. Organizing policy through a common decision service can reduce inconsistency, but only if failures are handled safely and critical entry points cannot bypass the decision.

Role-based policy is economical when roles correspond to real organizational responsibilities. For example, a student's own transcript read permission may be separate from the lecturer's grade-entry permission. Overloading a generic 'staff' role with every administrative action expands exposure if any staff account is compromised. Attribute-based rules can include course assignment, data sensitivity, and request timing. Relationship-based rules can represent group membership and ownership. Policy-as-code can make authorization rules version-controlled, reviewed, and testable. The choice of representation should make security invariants easy to verify, not merely produce compact source code.

Separation of duties protects against errors and misuse by requiring different actors for conflicting stages of a sensitive operation. For example, the employee who requests a change to payment instructions need not be the same employee who approves it. The two-person rule is weaker if both approvals come from a shared identity or if the second approver sees only a generic 'approve' button without the underlying change details. Effective approval workflows record the intended action, requester, approver, policy version, and immutable evidence of the decision. They also define how an emergency change is handled without normalizing permanent bypasses.

Delegation introduces another subtle requirement: a delegated permission should not exceed the authority of the grantor. If a tutor may read submissions for one course, the tutor cannot validly issue a link that allows a stranger to export all institution records. Capability-style access links can simplify narrow sharing, but they are bearer secrets and require scoped action, expiration, and revocation handling. Sharing a link through an uncontrolled chat may compromise confidentiality even when the link is cryptographically unpredictable. Auditability, discoverability, and delegation usability must be balanced; overcomplicated sharing systems encourage workarounds and often weaken practical security.

Policy evaluation may use environmental attributes such as risk score, device posture, or network location. These indicators are informative, not infallible. A trusted office network can contain a compromised computer; a roaming student's unfamiliar location does not prove malice. The safest approach usually combines stable permissions with adaptive safeguards for high-impact actions. When a context provider fails, define whether the application denies, degrades functionality, or requests stronger authentication. Unspecified fallback behavior is a common source of authorization gaps after network incidents and identity-provider outages.

Periodic access reviews should examine effective permissions rather than merely assigned role names. Group nesting, inherited access, stale external collaborators, emergency exceptions, and service credentials often make the effective privilege set broader than expected. An automated report can compute who can reach which resources under representative scenarios, but a human owner still needs to decide whether the access has a justified business purpose. For auditable outcomes, record revocation decisions and verify enforcement after the review. A spreadsheet listing old accounts is not evidence that those accounts can no longer call an API.

Threat-oriented test method. Construct an authorization matrix including active members, expired members, external collaborators, service jobs, administrators, and suspended accounts. Test resource reads, updates, exports, and administrative operations, plus denial cases. Re-run after policy edits. For each denial, verify no side effect, not just a 403 response. Verify policy behavior when the cache is stale, the time source differs, and the identity provider is temporarily unavailable. These deliberately bounded negative tests use test data and test accounts, never other people's live resources.

Privacy concerns the appropriate collection, use, retention, disclosure, and control of information about people. Confidentiality is important but incomplete: a system can encrypt a dataset perfectly and still harm individuals by collecting it without a legitimate purpose or by using it for an unexpected decision. Security engineering should therefore ask not only 'Can an attacker read these records?' but also 'Why is this field collected? Who is allowed to use it? What inferences can be drawn when datasets are combined? How long must it remain?' A policy document that claims strong privacy while the implementation retains identifiable logs indefinitely is not a sound privacy design.

Data minimization means gathering and retaining information necessary for a stated purpose, subject to actual obligations and user needs. It should be applied at the field, precision, retention, access, and query levels. A library recommendation feature may need broad subject preferences, not an exact home address. A safety incident may justify temporary detailed logs, but ordinary site analytics may function with aggregate counts. When processing is optional, give a meaningful preference rather than treating silence as full authorization for every future use. Technical controls such as short retention, field separation, fine-grained access, and delayed aggregation can make such promises enforceable.

De-identification is not a magic operation performed by deleting names. Unusual combinations of course enrollment, timestamps, locations, or rare conditions may identify a person when combined with other information. Re-identification risk depends on an adversary's auxiliary knowledge, the dataset's granularity, the number of people with similar attributes, and the release mechanism. Pseudonymization replaces direct identifiers with substitutes but normally leaves a linkage mechanism and other identifying patterns. The resulting data can still be personal data under relevant laws and institutional policies. Publishing individual-level 'anonymous' records without a defensible disclosure analysis can be unsafe even if every student ID has been replaced with a random string.

Aggregation can reduce identifiability when groups are sufficiently broad, but small counts may disclose sensitive membership. Consider a report showing one student in a rare combination of department and scholarship category. Suppression of small cells can help, but complementary cells and repeated reports can reconstruct hidden counts. Privacy reviews should examine multiple releases together, not each report in isolation. Differential privacy provides a mathematical bound on how much an algorithm's output distribution can change when one individual's data is added or removed, under explicit adjacency and randomization assumptions. It is not equivalent to simply adding arbitrary noise to a spreadsheet. Its guarantees require carefully managed privacy budgets, trustworthy implementations, and an understanding of which questions are being answered.

Privacy impact analysis should follow data across its lifecycle: collection, validation, primary storage, internal processing, external transfer, backup, incident logs, analytics, archival, and deletion. Deleting the primary database row while leaving personally identifying exports in shared folders is not complete deletion. Likewise, an encryption key removed from active service accounts may still be present in old backups if lifecycle controls are weak. Retention schedules need technical enforcement and documented exceptions for disputes, research ethics, or legal holds. Clear access and deletion controls reduce both privacy risk and the cost of future data governance.

Educational case. A department wishes to publish class-performance research. Rather than export row-level marks with dates and demographics, the team first states the research question: do students benefit from a new laboratory teaching method? A controlled analysis environment can compute summary outcomes, uncertainty measures, and relevant fairness checks without releasing identifiable rows. Researchers document selection bias and limitations. Reviewers consider whether small cohorts permit recognition, whether groups have consented or other valid processing grounds, and whether the institution's policy allows the purpose. Good privacy practice can improve statistical design by forcing explicit definitions of populations and observables.

Cryptographic primitives are only as effective as their key management and surrounding software. A modern encryption algorithm can be used in an insecure application if keys are embedded in client code, reused across unrelated purposes, copied without controls, or lost without a tested recovery plan. A complete lifecycle includes generation, registration, access restriction, usage, rotation, backup, compromise handling, revocation, archival, and destruction. Each phase needs an owner and an observable outcome. 'Rotate keys regularly' is not actionable unless the organization can identify which systems hold a key, what depends on it, and how an old key ceases to authorize sensitive operations.

Key types serve different purposes: symmetric encryption keys protect confidentiality and integrity when used with appropriate authenticated-encryption modes; asymmetric keys can support signatures, exchange, and authentication; key-encryption keys protect other stored keys. Reusing one key for unrelated purposes expands consequences when it is compromised and can violate assumptions of cryptographic constructions. Domain separation and context-specific key derivation help establish clear boundaries. Implementations should rely on maintained cryptographic libraries and key-management services, not custom ciphers or hand-rolled protocols invented as learning exercises for production use.

Entropy and unpredictability are central to secret generation. A uniformly generated 128-bit key has 2^128 possible values, which is extraordinarily large for direct exhaustive guessing under the assumed model. But a 128-bit field filled with human-selected patterns does not provide 128 bits of entropy. Likewise, choosing a cryptographic random function does not compensate for reading its seed from a predictable source. Reliability problems can also compromise keys: an application that logs all environment variables during startup may publish the secret even though its generator is excellent. Security analysis must inspect both generation and all subsequent exposure paths.

Rotation has compatibility and availability costs. When encrypted records are stored under an old key, simply deleting that key may render records irrecoverable. A common design separates data encryption keys from a wrapping key and records metadata indicating which key version protects an object. When a wrapping key changes, the system can rewrap data keys rather than decrypt and re-encrypt every large object, depending on threat requirements and key-service capabilities. If a data key itself is believed exposed, rewrapping that compromised key may be insufficient: affected plaintext may already have leaked, and re-encryption may be necessary to restore future confidentiality. Compromise response must identify the nature of exposure rather than applying a ritual rotation without analysis.

Backup and recovery introduce a tension. Keys needed to restore encrypted backups must remain accessible to a carefully controlled recovery process; placing every key in the same online database as ciphertext undermines separation, while storing the only copy on one employee's laptop creates continuity risk. High-assurance systems may use hardware-backed protection, split authorization, and formal recovery ceremonies, but these require rehearsed procedures to remain usable. An inaccessible recovery key can be as damaging operationally as a leaked one. For small services, a managed key facility, narrow service identities, tested restores, and owner documentation are more useful than an elaborate architecture nobody knows how to operate.

Review exercise. Draw two separate maps: a data-flow diagram and a key-flow diagram. Show where ciphertext is created, which service can request decryption, which identity is checked, which audit event is generated, how keys are versioned, and what happens when access is revoked. Include failure states: unavailable key service, lost session, malformed ciphertext, missing metadata, and recovery from a backup. Test each state with synthetic data. A sound design avoids turning an exceptional recovery operation into a permanent path around routine authorization controls.