Tutorial 3.2: Identity, Authentication, Authorization, and Accounting (IAAA)

← Previous Tutorial (3.1) | Table of Contents | Unit Home | Next Tutorial (3.3) →

Table of Contents

Learning Objectives

After completing this tutorial, you should be able to:

Overview

In Tutorial 3.1, we introduced the IAAA framework—Identification, Authentication, Authorization, and Accounting—as a structured way to understand security enforcement. We established that these four functions work in concert to protect systems and data. In this tutorial, we dive much deeper into each component of the framework, exploring the theories, architectures, standards, and operational practices that make IAAA the cornerstone of modern identity and access management (IAM).

The IAAA framework is not merely a checklist of functions; it is a holistic approach to security that recognizes the interdependence of identity verification, permission management, and activity monitoring. A failure in any one component can undermine the entire security posture. For example, strong authentication (e.g., MFA) is rendered ineffective if authorization is overly permissive; similarly, comprehensive auditing is of little value if authentication is weak and identities cannot be trusted.

We begin this tutorial by examining each element of IAAA in detail. Identification establishes a claimed identity—the "who" of the interaction. Authentication verifies that claim through evidence (factors). Authorization determines what actions the authenticated entity may perform. And Accounting records what actually happened, providing the data needed for monitoring, compliance, and forensic investigation.

We then turn to the concept of digital identity, exploring how identities are represented, stored, and managed across systems. We examine the identity lifecycle—provisioning, maintenance, and de-provisioning—and discuss the operational challenges of managing identities at scale. The tutorial also covers authentication assurance and the NIST Digital Identity Guidelines (SP 800-63), which provide a standardized framework for evaluating authentication strength.

We explore authorization models and enforcement mechanisms, including policy-based and attribute-based approaches, and we discuss the separation of policy decision and policy enforcement (PDP/PEP). The accounting section covers logging, auditing, and monitoring, including the role of Security Information and Event Management (SIEM) systems and the importance of audit trails for compliance.

The tutorial also addresses trust relationships and identity federation, which enable organizations to extend IAAA across administrative boundaries. We examine the roles of identity providers (IdPs) and service providers (SPs) and discuss federation standards such as SAML and OAuth.

Finally, we look at IAAA in practice, examining common architectures, deployment patterns, and the challenges of implementing IAAA in complex enterprise environments. Two detailed case studies—one from the financial sector and one from a large university—illustrate how IAAA principles are applied in real-world contexts.

By the end of this tutorial, you will have a comprehensive understanding of the IAAA framework and the practical considerations that go into designing, deploying, and operating identity and access management systems.

1. The IAAA Framework in Depth

1.1 Identification: Claiming an Identity

Identification is the act of presenting an identifier to a system. An identifier is a unique label that distinguishes one entity from another within a given context. Common identifiers include:

Identification itself does not imply trust. It is simply a claim: "I am entity X." The system must then verify this claim through authentication. However, identification is a critical first step because it determines which identity will be authenticated and authorized.

1.1.1 Identity Attributes and Claims

Beyond the primary identifier, a digital identity may have associated attributes—pieces of information about the entity. These attributes can include:

In identity management, these attributes are often expressed as claims—assertions about the identity that can be used by authorization systems to make access decisions. For example, a claim might be "this user is a member of the Finance department" or "this user has the 'Administrator' role."

1.2 Authentication: Verifying the Claim

Authentication is the process of verifying the identity claim. The goal is to obtain sufficient evidence that the entity presenting the identifier is indeed the legitimate owner of that identity. As discussed in Tutorial 3.1, authentication relies on one or more factors:

Authentication can be single-factor (one factor) or multi-factor (two or more factors from different categories). The level of assurance provided by authentication depends on the number and strength of the factors used, as well as the security of the authentication protocol itself.

1.2.1 Authentication Assurance Levels (AAL)

The NIST Digital Identity Guidelines (Special Publication 800-63-3) define three levels of authentication assurance:

AAL Description Examples Risk Context
AAL 1 Some confidence in the asserted identity. Single-factor authentication (e.g., password). Standard username/password login, low-risk applications. Low risk; minimal consequences of compromise.
AAL 2 High confidence in the asserted identity. Two-factor authentication (e.g., password + TOTP or security key). Enterprise logins, online banking, email accounts with MFA. Moderate risk; consequences of compromise are significant.
AAL 3 Very high confidence. Hardware-based cryptographic authentication, with resistance to phishing and man-in-the-middle attacks. FIDO2/WebAuthn security keys, PIV/CAC smart cards for government systems. High risk; compromise could lead to major financial, legal, or national security impact.

Organizations should select the appropriate AAL based on a risk assessment. Higher AALs require stronger authentication mechanisms and more sophisticated identity proofing processes.

1.3 Authorization: Granting Permissions

Authorization is the process of determining what an authenticated entity is permitted to do. It answers the question: "Is this entity allowed to perform this action on this resource?" Authorization is distinct from authentication: authentication establishes who you are; authorization establishes what you can do.

Authorization policies define the rules that govern access decisions. These policies can be expressed in various forms:

Authorization decisions are typically made by a Policy Decision Point (PDP) and enforced by a Policy Enforcement Point (PEP). The PDP evaluates the access request against the policy and returns a decision (permit, deny, or perhaps a conditional response). The PEP intercepts the request, consults the PDP, and enforces the decision.

1.4 Accounting: Recording and Monitoring

Accounting (also known as auditing) is the process of recording the activities of authenticated and authorized entities. It provides a historical record of what happened, when it happened, who did it, and what resources were involved. Accounting serves multiple purposes:

Accounting relies on audit logs—systematic records of events. Modern security operations centers (SOCs) use Security Information and Event Management (SIEM) systems to collect, correlate, and analyze audit logs from across the enterprise.

Key Takeaway: The IAAA framework provides a comprehensive approach to security enforcement. Identification establishes who is attempting to act; authentication verifies that claim; authorization determines what actions are permitted; and accounting records what actually happened. These four functions are interdependent and must be designed and operated as a unified system.

2. Digital Identity: Concepts and Representation

2.1 What Is Digital Identity?

A digital identity is the digital representation of an entity (a person, organization, device, or application) within a system or across systems. It is the set of attributes and claims that define the entity in the digital world. Digital identity is not a single, monolithic object; it is a collection of data that may be distributed across multiple repositories and used for different purposes.

The concept of digital identity is fundamental to IAAA because it is the entity that is identified, authenticated, authorized, and accounted for. A digital identity may include:

2.2 Identity Repositories

Digital identities are stored in identity repositories. The most common types include:

In large organizations, identities are often synchronized across multiple repositories, with a central source of truth (the "system of record") from which changes are propagated to other systems.

2.3 Identity Models: Isolated, Federated, and Centralized

There are three primary models for identity management:

  1. Isolated (Siloed) Identity: Each application or system maintains its own identity store. Users have separate credentials for each system. This model is simple to implement but creates management overhead and user frustration (password fatigue).
  2. Centralized Identity: A single identity repository serves as the authoritative source for all identities across the organization. Users have a single set of credentials for all systems. This simplifies management and improves user experience but creates a single point of failure.
  3. Federated Identity: Multiple organizations agree on trust relationships that allow users from one organization to access resources in another using their home credentials. This is the model used for single sign-on (SSO) across organizational boundaries.
┌─────────────────────────────────────────────────────────────────────────────┐ │ IDENTITY MANAGEMENT MODELS │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ ISOLATED (SILOED) CENTRALIZED FEDERATED │ │ │ │ ┌───┐ ┌───┐ ┌───┐ ┌─────────────────┐ ┌──────────┐ │ │ │ A │ │ B │ │ C │ │ Central IdP │ │ IdP A │──┐ │ │ └───┘ └───┘ └───┘ │ (Single Store) │ └──────────┘ │ │ │ | | | └────────┬────────┘ │ │ │ │ (separate credentials) │ │ │ │ │ │ ┌────┴─────┴────┐ │ │ ┌─┴─┐ │ SP A SP B │ │ │ │App1│ └───────────────┘ │ │ └───┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘

Figure 1: Identity management models: isolated, centralized, and federated.

3. The Identity Lifecycle

Digital identities are not static. They are created, modified, and eventually decommissioned over time. The identity lifecycle encompasses the entire span of an identity's existence, and effective lifecycle management is essential for maintaining security and compliance.

3.1 Provisioning

Provisioning is the process of creating a new digital identity and assigning the appropriate attributes and entitlements. Provisioning is typically triggered by a business event such as:

During provisioning, the following steps are typically performed:

  1. Identity proofing: Verifying the identity of the person or entity (e.g., through government ID, background check, or other means).
  2. Account creation: Creating the account in the identity repository and any downstream systems.
  3. Credential issuance: Generating and distributing credentials (e.g., temporary password, smart card, biometric enrollment).
  4. Entitlement assignment: Assigning roles, groups, and permissions based on the user's job function and organizational needs.

3.2 Maintenance

Maintenance refers to the ongoing updates and changes to an identity during its active lifetime. Maintenance activities include:

3.3 De-Provisioning

De-provisioning is the process of removing or suspending an identity when it is no longer needed. De-provisioning is triggered by events such as:

De-provisioning must be performed promptly and thoroughly to prevent orphaned accounts—accounts that remain active but have no legitimate owner. Orphaned accounts are a common vector for security breaches.

Critical Consideration: De-provisioning is often the most neglected phase of the identity lifecycle. Organizations should implement automated de-provisioning workflows that ensure accounts are disabled immediately upon termination or role change, with appropriate data retention and archival policies.

4. Authentication: Assurance and Trust

4.1 Authentication Strength and Assurance

The strength of an authentication system depends on several factors:

4.2 NIST Digital Identity Guidelines (SP 800-63)

The NIST Digital Identity Guidelines provide a comprehensive framework for identity management, including identity proofing, authentication, and federation. The guidelines are organized into three volumes:

Key concepts from SP 800-63B include:

NIST SP 800-63B provides specific technical requirements for each AAL, including password policies, MFA requirements, and cryptographic standards.

4.3 Authentication Protocols and Security

Authentication protocols are the mechanisms by which authentication is performed. Common protocols include:

Each protocol has its own security properties and threat models. A robust authentication architecture may combine multiple protocols to support different use cases and assurance levels.

5. Authorization: Policies and Enforcement

5.1 Authorization Models

Authorization models define how permissions are assigned and how access decisions are made. The major models include:

Each model has its strengths and weaknesses. In practice, modern systems often combine elements of RBAC and ABAC, using roles as the primary mechanism and attributes for fine-grained, dynamic decisions.

5.2 Policy Decision and Enforcement Points

The Policy Decision Point (PDP) is the component that evaluates access requests against the policy and returns a decision. The Policy Enforcement Point (PEP) is the component that intercepts requests, consults the PDP, and enforces the decision. This separation of concerns is a key architectural pattern in modern access control systems.

┌─────────────────────────────────────────────────────────────────────────────┐ │ POLICY DECISION AND ENFORCEMENT │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────┐ Access Request ┌─────────┐ Evaluate ┌─────────┐ │ │ │ Subject │───────────────────►│ PEP │─────────────►│ PDP │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ┌─────┴─────┐ ┌───────┴───────┐ │ │ │ │ Enforce │ │ Policy │ │ │ │ │ Decision │ │ Repository │ │ │ │ └───────────┘ └───────────────┘ │ │ │ │ │ │ │ Permit / Deny │ │ │ │◄─────────────────────────────┘ │ │ │ │ │ ┌───┴───┐ │ │ │ Access│ │ │ │ Result│ │ │ └───────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘

Figure 2: Policy Decision Point (PDP) and Policy Enforcement Point (PEP) interaction.

5.3 Authorization Policies in Practice

In enterprise environments, authorization policies are typically expressed using:

6. Accounting: Logging, Auditing, and Monitoring

6.1 The Role of Accounting in IAAA

Accounting provides the "A" that is often overlooked in IAAA but is critical for security, compliance, and operational management. Accounting activities include:

6.2 Audit Log Content

An effective audit log should capture the following information for each event:

The NIST SP 800-92 (Guide to Computer Security Log Management) provides best practices for logging and log management.

6.3 SIEM and Security Monitoring

Security Information and Event Management (SIEM) systems collect, aggregate, and analyze log data from across the enterprise. SIEMs provide:

Key Takeaway: Accounting is not an afterthought—it is an integral part of the IAAA framework. Without effective accounting, organizations cannot detect breaches, investigate incidents, or demonstrate compliance. Security monitoring and SIEM are essential tools for operationalizing accounting.

7. Trust Relationships and Identity Federation

7.1 What Is Identity Federation?

Identity federation enables users from one organization to access resources in another organization using their home credentials. Federation is based on trust relationships between organizations, where one organization (the Identity Provider or IdP) authenticates the user and provides assertions about the user's identity to another organization (the Service Provider or SP).

Federation is the foundation of single sign-on (SSO) across organizational boundaries and is widely used in web applications, cloud services, and enterprise collaborations.

7.2 Federation Architecture

A typical federation architecture includes the following components:

┌─────────────────────────────────────────────────────────────────────────────┐ │ FEDERATED IDENTITY ARCHITECTURE │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────────┐ ┌──────────────────┐ │ │ │ │ │ │ │ │ │ Identity │ SAML / OIDC │ Service │ │ │ │ Provider │◄────────────────────────────►│ Provider │ │ │ │ (IdP) │ │ (SP) │ │ │ │ │ │ │ │ │ └────────┬─────────┘ └────────┬─────────┘ │ │ │ │ │ │ │ 1. User authenticates │ │ │ │ at IdP │ │ │ │ │ │ │ ┌────────┴─────────┐ ┌────────┴─────────┐ │ │ │ User │ 2. Redirect to SP │ Protected │ │ │ │ (Browser) │ with assertion │ Resource │ │ │ │ │─────────────────────────────►│ │ │ │ └──────────────────┘ └──────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘

Figure 3: Federated identity architecture with IdP and SP.

7.3 Federation Protocols and Standards

The most widely used federation standards include:

8. IAAA in Practice: Architectures and Deployments

8.1 Common IAAA Architectures

IAAA architectures vary based on organizational size, risk profile, and technical environment. Common patterns include:

8.2 Identity Governance and Administration (IGA)

Identity Governance and Administration (IGA) encompasses the policies, processes, and technologies used to manage digital identities and their access rights. IGA includes:

8.3 Challenges in IAAA Deployment

Organizations face numerous challenges when deploying IAAA systems:

Best Practice: Organizations should adopt a phased approach to IAAA deployment, starting with authentication and authorization for high-risk applications, then expanding to identity governance and federation over time. A "crawl-walk-run" strategy reduces risk and builds organizational capability.

9. Case Studies

9.1 Case Study: Financial Services IAM Transformation

Background: A global financial services firm with 50,000 employees and 10 million customers operates across 40 countries. The firm faces stringent regulatory requirements (SOX, GLBA, GDPR) and must protect sensitive financial data against sophisticated cyber threats.

Challenges:

Solution: The firm implemented a comprehensive IAAA transformation:

Outcome: The firm reduced identity-related security incidents by 80% over two years, achieved all regulatory compliance targets, and improved user satisfaction through SSO and automated provisioning.

9.2 Case Study: University Federated Identity

Background: A large public university with 30,000 students, 5,000 faculty and staff, and hundreds of academic departments and administrative units. The university uses a variety of cloud-based services (Microsoft 365, Google Workspace, Canvas LMS, and numerous research applications) and must support students and researchers collaborating with external institutions.

Challenges:

Solution: The university deployed a federated identity architecture:

Outcome: The university achieved seamless SSO for students and faculty, enabling access to a wide range of services with a single set of credentials. Federation with InCommon facilitated collaborative research and reduced administrative overhead.

10. Summary and Transition

In this tutorial, we have explored the IAAA framework in depth, examining each component—identification, authentication, authorization, and accounting—and their interdependence. We have seen that digital identity is the central concept around which IAAA revolves, and we examined the identity lifecycle from provisioning to de-provisioning.

We explored authentication assurance levels (AAL) as defined by NIST SP 800-63 and discussed the importance of choosing the appropriate AAL based on risk. We examined authorization models, including RBAC and ABAC, and the architectural pattern of PDP and PEP. We also explored the role of accounting in security monitoring, incident response, and compliance.

Trust relationships and identity federation were discussed as essential mechanisms for extending IAAA across organizational boundaries. We examined the roles of identity providers and service providers and the standards (SAML, OAuth, OIDC) that enable federation.

Finally, we looked at IAAA in practice through two case studies—one from financial services and one from higher education—that illustrate how IAAA principles are applied in complex enterprise environments.

This tutorial has provided a comprehensive understanding of the IAAA framework. In the next tutorial, Tutorial 3.3, we will focus specifically on password-based authentication, examining password policies, password storage, password cracking techniques, and modern password management practices.

Quiz

Answer the following questions to check your understanding. Click the "Answer" button to reveal the solution.

Q1. Which component of the IAAA framework is responsible for determining what actions an authenticated entity is permitted to perform?

Answer
C) Authorization. Authorization determines what permissions an authenticated entity has.

Q2. According to NIST SP 800-63B, which Authentication Assurance Level (AAL) requires two-factor authentication with phishing resistance?

Answer
C) AAL 3. AAL 3 requires hardware-based cryptographic authentication with phishing resistance.

Q3. What is the primary purpose of accounting in the IAAA framework?

Answer
C) To record and monitor user activities. Accounting provides audit trails and supports security monitoring.

Q4. In a federated identity architecture, the system that authenticates users and issues assertions is called the:

Answer
B) Identity Provider (IdP). The IdP authenticates users and issues assertions to Service Providers.

Q5. Which of the following is not a phase of the identity lifecycle?

Answer
C) Federation. Federation is a model of identity management, not a phase of the identity lifecycle.

Q6. What is the role of the Policy Decision Point (PDP) in an authorization architecture?

Answer
B) The PDP evaluates access requests against policies and returns a decision (permit/deny).

Q7. Which federation protocol is built on top of OAuth 2.0 and provides authentication capabilities?

Answer
C) OpenID Connect (OIDC). OIDC is an identity layer built on top of OAuth 2.0.

Q8. An orphaned account is:

Answer
B) An account that remains active but has no legitimate owner. Orphaned accounts are a security risk.

Q9. Which of the following best describes the relationship between authentication and authorization?

Answer
B) Authentication establishes who you are; authorization determines what you can do.

Q10. What is the primary goal of identity governance and administration (IGA)?

Answer
B) To manage the full lifecycle of digital identities and their access rights, including access certifications and compliance.

Q11. In the context of authentication, what is a "factor"?

Answer
B) A category of evidence used to verify identity. The three primary factors are knowledge, possession, and inherence.

Q12. Which statement about identity federation is true?

Answer
B) Federation requires trust relationships between organizations, enabling users to access resources across boundaries.

Exercises

These exercises are designed to help you apply the concepts from this tutorial. Attempt each exercise before revealing the sample solution.

Exercise 3.2-1: IAAA Scenario Analysis

Consider the following scenario: A user logs into an online banking system. The system verifies the user's password and a one-time code sent to their phone. The system then checks whether the user has the "Customer" role and grants access to their account balances and transaction history. All transactions are logged with timestamps and the user's IP address.

  1. Identify each step in the scenario with the corresponding IAAA component.
  2. Explain how the system's architecture supports the separation of authentication and authorization.
  3. What additional accounting information could the system capture to improve security monitoring?
Sample Solution
  1. IAAA mapping:
    • Identification: User enters their username (or account number) to claim an identity.
    • Authentication: System verifies password and one-time code (MFA).
    • Authorization: System checks the "Customer" role and grants access to specific resources (account balances, transactions).
    • Accounting: All transactions are logged with timestamps and IP addresses.
  2. Separation of authentication and authorization: The system has distinct components for each function. Authentication verifies the user's identity (using credentials), while authorization determines what resources the user can access (using role information). This separation allows for independent scaling, policy updates, and security monitoring.
  3. Additional accounting information:
    • Device fingerprint or user agent string
    • Session ID and session duration
    • Geolocation data (from IP or GPS)
    • Success/failure status of each authorization check
    • Changes to user profile or preferences
    • Failed authentication attempts and reasons

Exercise 3.2-2: Authentication Assurance Level Selection

An organization is implementing authentication for three different use cases:

  1. Use Case A: Public-facing website for informational content (no sensitive data).
  2. Use Case B: Employee portal for accessing HR records, payroll, and internal applications.
  3. Use Case C: System administrator access to critical infrastructure servers.

For each use case, recommend an appropriate NIST AAL level (AAL 1, 2, or 3) and justify your recommendation. Describe the authentication mechanisms you would deploy for each.

Sample Solution
  • Use Case A (Public website, no sensitive data): AAL 1. The risk is low, and the impact of a compromise is minimal. Authentication could be optional or use simple username/password. MFA is not required.
  • Use Case B (Employee portal, HR/payroll data): AAL 2. The risk is moderate—unauthorized access could expose sensitive personal information. Deploy MFA with password + TOTP (authenticator app) or password + security key. Implement risk-based step-up authentication for high-risk actions.
  • Use Case C (System administrator, critical infrastructure): AAL 3. The risk is high—compromise could lead to severe operational and security consequences. Deploy phishing-resistant authentication such as FIDO2/WebAuthn hardware security keys, with mandatory MFA and strong cryptographic protections. Implement just-in-time (JIT) privilege elevation and session monitoring.

Exercise 3.2-3: Identity Lifecycle Design

Design an identity lifecycle management process for a mid-sized organization (2,500 employees) with a mix of on-premises and cloud applications. Your design should cover:

  1. Provisioning (new employees, contractors, interns)
  2. Maintenance (role changes, credential management, access reviews)
  3. De-provisioning (terminations, role changes, temporary suspensions)
  4. How the process integrates with the organization's HR system
  5. How the process ensures compliance with data protection regulations
Sample Solution

Identity Lifecycle Management Design

  • Provisioning:
    • HR system triggers account creation on day 1 (or as part of pre-boarding).
    • Automated workflows create accounts in Active Directory, Azure AD, and core applications.
    • Role assignment based on job function, department, and location.
    • Credentials are securely delivered (temporary password with forced change on first login).
    • MFA enrollment is required within 24 hours.
  • Maintenance:
    • Role changes are synchronized from HR to identity systems.
    • Automated entitlement adjustments based on role assignments.
    • Quarterly access reviews: managers certify their team members' access rights.
    • Self-service password reset and MFA management through a portal.
    • Annual comprehensive identity and access governance review.
  • De-provisioning:
    • Immediate deactivation upon termination (HR trigger).
    • Access to all applications is removed within minutes.
    • Data transfer and archival processes for departing employees.
    • Contractor accounts have fixed expiry dates with renewal workflows.
    • Orphaned account detection and cleanup (automated).
  • HR Integration: Identity system integrates with HR system via APIs (e.g., SCIM). HR events (hire, transfer, terminate) automatically trigger identity workflows.
  • Compliance:
    • All provisioning, maintenance, and de-provisioning actions are logged.
    • Access reviews are documented and stored for audit purposes.
    • Separation of duties (SoD) policies are enforced.
    • Data retention and deletion policies align with GDPR and other regulations.

Exercise 3.2-4: Federation Architecture Design

A large university wants to enable its students to access cloud-based learning management systems (LMS) and research collaboration platforms hosted by external providers. Design a federated identity architecture that:

  1. Uses the university's existing identity repository (Active Directory) as the source of truth.
  2. Supports both SAML 2.0 and OpenID Connect/OAuth 2.0.
  3. Provides single sign-on (SSO) for students and faculty.
  4. Includes step-up authentication for access to sensitive resources (e.g., grades, personal information).
  5. Describes how trust relationships are established with external service providers.
Sample Solution

Federated Identity Architecture Design

  • Core components:
    • Identity Provider (IdP): Azure AD (or AD FS) as the central IdP, with Active Directory as the source of truth.
    • Federation gateway: A federation proxy that handles SAML 2.0, OAuth 2.0, and OpenID Connect.
    • MFA service: Azure MFA or a third-party service for step-up authentication.
  • Workflow:
    • Student accesses LMS → redirected to IdP → authenticated via Azure AD with MFA (if required) → SAML assertion sent to LMS → access granted.
    • For OIDC-enabled applications, the same flow uses OAuth 2.0/OIDC.
  • Step-up authentication: For access to sensitive resources (grades, personal info), the application initiates a step-up authentication request. The IdP prompts for additional MFA (e.g., security key) before returning the assertion.
  • Trust relationships:
    • The university establishes a trust relationship with each external SP by exchanging metadata (certificates, endpoints).
    • For SAML: metadata exchange and digital signatures.
    • For OAuth/OIDC: client registration and client secret/key exchange.
    • The university may join a federation (e.g., InCommon) to streamline trust establishment with multiple SPs.
  • Additional considerations:
    • SCIM provisioning for automated user and group provisioning in partner applications.
    • Session management: SAML sessions, refresh tokens, and automatic logout.
    • Auditing: all authentication and authorization events are logged for compliance.

Exercise 3.2-5: IAAA Troubleshooting

An organization has deployed a new IAAA system. Users are reporting the following issues:

  1. Users can log in successfully but cannot access resources they should be able to access.
  2. Users are receiving "access denied" errors even after successful authentication.
  3. Some users can access resources they should not have access to (privilege escalation).
  4. Audit logs are incomplete for certain critical systems.

For each issue, identify the likely IAAA component(s) at fault and propose a troubleshooting approach. What security implications does each issue have?

Sample Solution
  • Issue 1 (Login success, but no access):
    • Likely component: Authorization (role/permission mapping).
    • Troubleshooting: Check user's role assignment, group memberships, and object-level permissions. Verify that the authorization policy is correctly applied. Check if the user's attributes (department, location) are correct.
    • Security implication: Users may be unable to do their jobs, leading to productivity loss. Could indicate a misconfiguration that affects many users.
  • Issue 2 (Access denied after authentication):
    • Likely component: Authorization (PDP/PEP configuration).
    • Troubleshooting: Check the policy evaluation logs. Verify that the PEP is correctly configured and can reach the PDP. Test with a known good user to isolate whether the issue is user-specific or system-wide.
    • Security implication: Denial of service for legitimate users; may indicate a failing enforcement mechanism that could also fail to block unauthorized access.
  • Issue 3 (Unauthorized access):
    • Likely component: Authorization (overly permissive policies, missing SoD checks).
    • Troubleshooting: Audit the user's role and permission assignment. Check for inherited permissions from groups. Look for policy misconfigurations or unexpected role assignments. Review segregation of duties (SoD) violations.
    • Security implication: High risk; potential data breach or fraud. Immediate investigation required.
  • Issue 4 (Incomplete audit logs):
    • Likely component: Accounting (logging configuration).
    • Troubleshooting: Check the logging configuration for the affected systems. Ensure that all systems are configured to send logs to the SIEM. Verify that log levels are appropriate and that logs are not being truncated.
    • Security implication: Inability to detect or investigate incidents; compliance violations.

Homework

These homework questions require deeper analysis, research, and application. Answer each question comprehensively.

Homework 3.2-1: IAAA Framework Comparison

Compare and contrast the IAAA framework with alternative security frameworks such as the CIA triad (Confidentiality, Integrity, Availability) and the Parkerian Hexad. In a 750–1,000 word analysis, discuss:

  1. How IAAA complements and extends these frameworks.
  2. Where IAAA addresses security concerns that the CIA triad does not explicitly cover.
  3. How the IAAA framework aligns with the Zero Trust security model.
  4. At least two real-world scenarios where IAAA provides superior security enforcement compared to using CIA triad alone.
Sample Answer

IAAA Framework Comparison

  • CIA triad: Focuses on confidentiality, integrity, and availability of data. IAAA complements the CIA triad by providing the operational mechanisms through which these goals are achieved. Authentication ensures confidentiality by protecting access to data; authorization ensures integrity by controlling modifications; accounting supports availability and integrity through monitoring and recovery. However, the CIA triad does not explicitly address identity management, trust, or accountability—areas where IAAA excels.
  • Parkerian Hexad: Extends the CIA triad with three additional properties: possession/control, authenticity, and utility. IAAA directly addresses authenticity (authentication) and possession/control (authorization). The Parkerian Hexad provides a richer framework for thinking about security, but IAAA offers a more actionable operational model.
  • Zero Trust alignment: IAAA is foundational to Zero Trust. Zero Trust requires continuous authentication (never trust, always verify), dynamic authorization (least privilege), and comprehensive accounting (monitoring and auditing). IAAA provides the operational framework to implement Zero Trust principles.
  • Real-world scenarios:
    • Scenario 1: Healthcare data access. IAAA ensures that only authenticated healthcare providers with proper authorization can access patient records. Accounting provides audit trails for compliance. The CIA triad alone would not enforce identity verification or role-based access.
    • Scenario 2: Financial transaction processing. IAAA ensures that only authorized personnel can approve transactions, that their identity is verified, and that all actions are recorded. The CIA triad would focus on data protection but would not address segregation of duties or auditability.

Homework 3.2-2: Identity Management Standards

Research the following identity management standards and frameworks: SCIM (System for Cross-domain Identity Management), SAML 2.0, OAuth 2.0, OpenID Connect, and FIDO2. Write a 750–1,000 word analysis that:

  1. Describes the purpose and scope of each standard.
  2. Explains how each standard fits into the IAAA framework (which IAAA components they address).
  3. Compares and contrasts the standards, highlighting their interoperability and the scenarios where each is most appropriate.
  4. Discusses the security properties of each standard (e.g., resistance to phishing, man-in-the-middle attacks).
  5. Provides recommendations for an enterprise that needs to support web authentication, API authorization, and identity federation.
Sample Answer

Identity Management Standards Analysis

  • SCIM (System for Cross-domain Identity Management): Automates user provisioning and de-provisioning across domains. Addresses the identity lifecycle (provisioning, maintenance, de-provisioning). RESTful API. Use case: synchronizing users between an HR system and cloud applications.
  • SAML 2.0: Exchanges authentication and authorization assertions between IdP and SP. Addresses authentication and authorization. XML-based. Use case: enterprise web SSO, federated identity.
  • OAuth 2.0: Authorization framework for granting delegated access to resources. Addresses authorization. Use case: API access, third-party applications, mobile apps.
  • OpenID Connect (OIDC): Identity layer on top of OAuth 2.0. Adds authentication capabilities. Addresses authentication and authorization. Use case: modern web and mobile applications, SSO.
  • FIDO2/WebAuthn: Passwordless, phishing-resistant authentication using public-key cryptography. Addresses authentication. Use case: high-assurance authentication, consumer and enterprise applications.
  • Comparison: SAML is best for enterprise web SSO; OAuth is best for API authorization; OIDC is best for modern web/mobile authentication; FIDO2 is best for phishing-resistant MFA. SCIM is complementary, providing provisioning automation.
  • Recommendations: For an enterprise, deploy OIDC for modern applications, SAML for legacy web applications, OAuth for API access, and FIDO2 for privileged accounts. Use SCIM for automated provisioning.

Homework 3.2-3: IAAA Implementation Plan

You are the lead security architect for a rapidly growing e-commerce company with 5,000 employees and 10 million customers. The company currently uses siloed authentication for its various systems (e.g., separate logins for the customer portal, employee portal, internal applications, and partner portal). The company wants to implement a comprehensive IAAA framework to improve security, user experience, and compliance. Develop an implementation plan that includes:

  1. An assessment of the current state and the gaps that need to be addressed.
  2. A target architecture that supports SSO for employees, customers, and partners.
  3. A phased implementation roadmap with clear milestones and timelines.
  4. Key success metrics and how you will measure them.
  5. Potential risks and mitigation strategies.
  6. A training and change management plan for employees and users.
Sample Answer

IAAA Implementation Plan

  • Current state assessment: Siloed authentication, multiple credentials per user, no MFA, manual provisioning, limited auditing. Gaps: inconsistent security, user frustration, compliance risk, operational inefficiency.
  • Target architecture: Centralized IAM platform (Okta or Azure AD) with SSO, MFA, automated provisioning (SCIM), and federation. Applications integrated via SAML/OIDC. SIEM for logging.
  • Phased roadmap:
    • Phase 1 (Months 1–3): Deploy central IdP, integrate employee-facing applications, implement MFA for employees.
    • Phase 2 (Months 4–6): Automate provisioning, integrate customer portal and partner portal.
    • Phase 3 (Months 7–9): Implement identity governance, access reviews, and federation with partners.
    • Phase 4 (Months 10–12): Zero Trust enhancements, adaptive authentication, and continuous monitoring.
  • Success metrics: Reduction in password reset tickets (≥80%), MFA adoption (≥99%), time to provision (≤ 5 minutes), security incident reduction (≥ 50%), compliance audits passed.
  • Risks and mitigation:
    • Risk: Integration challenges with legacy systems. Mitigation: Use federation proxies and middleware.
    • Risk: User resistance to MFA. Mitigation: Communication, training, and phased rollout with support.
    • Risk: Single point of failure (IdP). Mitigation: High availability and disaster recovery design.
  • Training and change management: Regular communication, training sessions, self-service resources, and a helpdesk support plan.

Homework 3.2-4: Authorization Policy Design

Consider the following access control requirements for a hospital's electronic health record (EHR) system:

Design an authorization policy using RBAC with ABAC extensions. Include:

  1. Role definitions and permissions.
  2. How attributes (e.g., patient assignment, emergency status) affect access decisions.
  3. How segregation of duties (SoD) is enforced.
  4. How emergency access is handled and audited.
  5. How the policy ensures compliance with HIPAA.
Sample Answer

Authorization Policy Design

  • Roles and permissions:
    • Physician: Read, create, update all clinical data for assigned patients. Can update diagnoses and treatment plans.
    • Nurse: Read all clinical data for patients on their unit; create and update vitals, care notes, and observations. Cannot update diagnoses or treatment plans.
    • Administrative Staff: Read demographic and billing information; no access to clinical data.
    • Patient: Read own records; no write access.
  • ABAC extensions:
    • Patient assignment: Only clinicians assigned to a patient can access that patient's records (with emergency exceptions).
    • Emergency status: When emergency mode is enabled, any clinician can access any patient's record.
    • Department/unit: Nurses are restricted to their unit's patients.
  • Segregation of duties (SoD): No single user can both create and approve a patient treatment plan. A physician creates the plan; a second physician (or supervisor) must approve high-risk treatments.
  • Emergency access: Emergency access is granted through a special override process. All emergency accesses are logged with justification, requiring review within 24 hours. Alerts are sent to the security team for any emergency access.
  • HIPAA compliance: Access is role-based with need-to-know. All accesses are logged for audit. Patient consent and data sharing controls are enforced. Emergency access is audited as required. Security policies are reviewed annually.

Homework 3.2-5: IAAA Research Paper

Write a research-style paper (1,500–2,000 words) on a current topic in identity and access management. Possible topics include:

Your paper should include:

  1. An abstract summarizing the topic and key arguments.
  2. An introduction that establishes the importance of the topic.
  3. A literature review or overview of current technologies and standards.
  4. Analysis of challenges, limitations, and open problems.
  5. A discussion of practical implications for organizations.
  6. Conclusions and recommendations for future research or practice.
  7. At least 10 references to academic papers, standards, or industry reports.
Sample Answer

Note: This is a research assignment. The sample answer below provides an outline and direction. Students are expected to produce a full research paper.

Sample Outline: Passwordless Authentication

  • Abstract: Passwordless authentication, using biometrics and cryptographic keys, offers enhanced security and user experience. This paper reviews the technologies, adoption challenges, and security implications of passwordless authentication in enterprise environments.
  • Introduction: Passwords are a persistent security weakness. Passwordless authentication addresses this by eliminating knowledge-based credentials.
  • Technologies: FIDO2/WebAuthn, biometrics, hardware security keys, and authentication apps.
  • Challenges: Deployment complexity, user acceptance, cost of hardware, and integration with legacy systems.
  • Security implications: Phishing resistance, reduced credential theft, but new risks (e.g., biometric data privacy, hardware token loss).
  • Recommendations: Phased adoption, starting with privileged accounts, with comprehensive user training and fallback options.
  • References: FIDO Alliance white papers, NIST SP 800-63B, industry reports (Gartner, Forrester), academic papers on authentication.

Summary

This tutorial provided a comprehensive exploration of the IAAA framework—Identification, Authentication, Authorization, and Accounting—which underpins modern identity and access management. We examined each component in depth, from the initial claim of identity through authentication, authorization, and the ongoing monitoring and recording of activities.

We explored the concept of digital identity and its representation across systems, and we discussed the identity lifecycle from provisioning to de-provisioning. We covered authentication assurance levels (AAL) as defined by NIST SP 800-63, and we examined the role of trust in authentication, including the importance of phishing-resistant authentication and the use of standards such as FIDO2.

Authorization was examined through the lens of policy-based access control, with a focus on the separation of policy decision and policy enforcement (PDP/PEP). We discussed the major authorization models—DAC, MAC, RBAC, and ABAC—and their practical applications. Accounting was explored through the lens of logging, auditing, and security monitoring, with an emphasis on SIEM systems and compliance requirements.

Trust relationships and identity federation were discussed as essential mechanisms for extending IAAA across organizational boundaries. We examined the roles of identity providers and service providers and the standards (SAML, OAuth, OIDC) that enable federation. We also explored the challenges of IAAA deployment at scale, including the need for identity governance and administration (IGA) and the importance of a phased, risk-based approach.

Through two detailed case studies—a financial services firm and a large university—we illustrated how IAAA principles are applied in complex, real-world environments. These case studies highlighted the importance of centralization, automation, and continuous improvement in IAAA programs.

This tutorial has equipped you with a deep understanding of the IAAA framework and its practical application. In the next tutorial, Tutorial 3.3, we will focus specifically on password-based authentication, examining password policies, password storage mechanisms (hashing, salting), password cracking techniques, and modern password management practices including password managers and passwordless alternatives.

← Previous Tutorial (3.1) | Table of Contents | Unit Home | Next Tutorial (3.3) →

© 2026 COMP400 – Computer and Network Security • School of Computing and Information Systems, TrustOpen University • Unit 3: Authentication and Access Control