Adaptive Authentication Design

Hello! Welcome back.

In our last lesson, we designed a robust system to assess a device's security posture before granting it access. We created a pipeline to collect signals like OS version and disk encryption, calculated a trust score, and used it to make an initial access decision. This was a crucial step in moving beyond simple identity verification.

However, the principle of "assume breach" requires us to be vigilant not just at the point of entry, but throughout the entire session. What happens if a user's device becomes non-compliant after they've already connected? Or if our identity provider detects that the user's account has been compromised? A session token, once issued, is typically valid until it expires, creating a dangerous window of exposure.

This lesson directly addresses that challenge and fulfills the learning outcome: Design a continuous authentication mechanism involving session risk scoring and real-time policy re-evaluation on signal changes. We will architect a system that moves from a static, one-time check to a dynamic, always-on verification model, enabling our ZTNA service to react instantly to changes in risk.

1. The Problem with Long-Lived Trust

Traditional session management, even using modern standards like JWTs, operates on a "trust-but-expire" model. A client authenticates, receives an access token with a set lifetime (e.g., one hour), and is trusted until that token expires.

The core problem is that there is no standard, built-in mechanism for the resource provider to check back with the identity provider to see if anything has changed. If a user's account is disabled or their password is stolen, a previously issued token remains valid.

To understand this problem from first principles, let's watch a short explanation of why this is a challenge in real-world identity systems.

As the video highlights, reducing the token lifetime to a few minutes can mitigate this, but it creates brittleness and increases load on the authentication system. The modern solution is to make the communication between the identity provider and the resource provider event-driven and continuous.

2. Architecting for Continuous Verification

To build a continuous authentication system, we need to design an architecture that can ingest various real-time signals, calculate a dynamic risk score for an active session, and trigger policy re-evaluation when that score changes.

Let's break down the core components of such a system.

Drawing from your experience with distributed systems, you'll recognize this as an event-driven architecture. The "Zero Trust MFA" article provides a great architectural blueprint for this.

Based on this blueprint, let's design our three key components.

Component 1: Context Signals Collection Layer

This layer is responsible for gathering all the data points—or "signals"—that inform session risk. We already designed a source for one critical signal in our last lesson: the device posture score. Now, let's expand the scope of signals we collect.

The following video provides a great overview of the types of signals used in risk-based authentication.

Synthesizing these ideas, our collection layer will need to ingest signals from multiple sources:

• Device Signals:
  • Device posture score (from the system we designed previously).
  • Sudden changes in device fingerprint (e.g., browser user-agent changes mid-session).
• Behavioral Signals:
  • "Impossible travel" (e.g., logins from New York and Beijing within 10 minutes).
  • Anomalous API usage patterns or data access volume.
  • Time-of-day anomalies (e.g., access at 3 AM from a 9-to-5 employee).
• Network Signals:
  • Changes in IP address, especially moving to an IP with a poor reputation.
  • Detection of traffic coming from a TOR exit node or an anonymous proxy.
• External Security Events:
  • A signal from your Identity Provider (IdP) that the user's password was just reset.
  • An alert from an Endpoint Detection and Response (EDR) tool that malware was found on the device.
  • A notification that the user's credentials appeared in a public data breach.

This last category—external events—is critical for a true Zero Trust model. Your ZTNA system doesn't operate in a vacuum. It must be able to listen and react to signals from the rest of your security ecosystem.

Component 2: The Session Risk Engine

The Risk Engine is the processing core of our system. Its job is to:

1. Ingest a continuous stream of signals for each active session.
2. Maintain a dynamic risk score for each session.
3. Compare this score against predefined policies.

The scoring logic can be similar to the weighted model we discussed for device posture, but applied continuously. For example:

• Initial Score: 80 (based on strong identity and compliant device at login).
• Signal: IP address changes to a known malicious IP. (-40 points)
• New Score: 40.
• Policy: If score < 60, terminate session.
• Action: The Risk Engine triggers a session termination event.

From a design perspective, you have a choice between a rule-based engine (like the example above) and a machine learning model.

• Rule-based: Deterministic, easy to debug, but can become complex to manage.
• ML-based: Can detect novel patterns and anomalies that rules might miss, but requires significant training data and can be a "black box," making decisions harder to audit.
  A hybrid approach is often best, using an ML model to flag anomalies and a rule-based system to make the final policy decision.

Component 3: The Policy Re-evaluation & Enforcement Mechanism

This is the most critical part of the design: how does the Risk Engine's decision get enforced in real-time? A simple polling mechanism, where the ZTNA proxy constantly asks "Is this session still valid?", introduces unacceptable latency. We need a push-based, event-driven mechanism.

This is where industry standards for sharing security signals become essential.

3. The Mechanism: Shared Signals and Continuous Access Evaluation

For different security products to communicate risk events in real-time, they need a common language and transport protocol. The Shared Signals Framework (SSF), developed at the OpenID Foundation, provides this standard.

A key profile within SSF is the Continuous Access Evaluation Protocol (CAEP). CAEP defines specific events related to session security.

Now, let's see how this is implemented in practice. When our ZTNA service (the resource provider) receives a CAEP event indicating a session is now risky, it needs to tell the client that its existing token is no longer valid and that it must re-evaluate its access.

The video we started with demonstrates this exact flow.

This 401 + claims challenge is the elegant architectural solution to our problem. It's a standard-based mechanism that cleanly terminates a risky session and forces a policy re-evaluation without relying on proprietary hacks or short token lifetimes.

4. End-to-End Design Flow

Let's trace a complete scenario through our architecture:

1. Initial Access: A user authenticates to your ZTNA service. Their identity is verified, and their device posture score is 95. The Session Risk Engine assigns an initial session risk score of low. A JWT is issued, and the user begins accessing an internal application through the ZTNA proxy (our Policy Enforcement Point).
2. Signal Change: Ten minutes later, your EDR tool (acting as an SSF Transmitter) detects that the user has disabled the local firewall on their device.
3. Event Transmission: The EDR tool generates a CAEP device-compliance-change Security Event Token (SET) and pushes it to your ZTNA system (acting as an SSF Receiver).
4. Risk Re-evaluation: The event is consumed by your Session Risk Engine. It re-calculates the score for the user's active session. The "firewall disabled" signal has a weight of -30, so the new score is 65.
5. Policy Trigger: A policy states that any session with a score below 70 is considered medium risk and requires step-up authentication.
6. Enforcement: The Risk Engine notifies the ZTNA proxy. The proxy flags the user's session for re-evaluation.
7. Client Challenge: The next time the user's client makes a request to the application, the ZTNA proxy intercepts it and returns a 401 Unauthorized HTTP response. The response header contains a claims challenge, indicating that a higher assurance level (e.g., MFA) is now required.
8. Resolution: The ZTNA client, being CAEP-aware, understands this response. It redirects the user to the identity provider to complete an MFA challenge. Upon success, a new token with the updated claims is issued, and the session continues, albeit now with a medium risk designation. If the user had instead disabled disk encryption (a -50 penalty), their score would have dropped to 45, crossing the high risk threshold and resulting in immediate session termination.

Conclusion

In this lesson, we have architected a sophisticated continuous authentication system that embodies the Zero Trust principle of "never trust, always verify." By moving from static, point-in-time checks to a dynamic, event-driven model, we can respond to changes in risk in near-real-time.

Key Takeaways:

• Continuous Authentication is Event-Driven: The core of the system is a Session Risk Engine that consumes a stream of signals about device, user, network, and application context.
• Risk Scoring is Dynamic: A session's trust level is not static; it is continuously calculated based on incoming signals, allowing for nuanced, risk-based policies.
• Standards are Key to Interoperability: The Shared Signals Framework (SSF) and its CAEP profile provide the common language for disparate security systems to communicate risk events in real time.
• Enforcement is Clean and Standardized: The 401 Unauthorized with a claims challenge pattern is the architectural mechanism used to force a client to re-evaluate its trust level in response to a risk change.

Preview of the Next Lesson:

So far in this module, we've designed systems to determine who can access what (identity), from what device (posture), and under what conditions (continuous risk). We have a powerful, dynamic access decision. The next logical step is to enforce this decision not just at the network edge, but deep within our internal network. In our next lesson, we will design a micro-segmentation enforcement model for ZTNA using identity-aware proxies and dynamic network policies, ensuring the principle of least privilege is applied between applications.