Solving the Continuous Authorization Conundrum

Zero Trust continues to present an often-overlooked challenge: keeping access decisions accurate as the real-world conditions behind them change. 

Over the past decade, AI, cloud transformation, mobile access, and remote work have challenged existing security paradigms at a fundamental level. Organizations have realized they must move from a “walled garden” security model, in which all computers inside a firewall or accessing via VPN are assumed to be trusted, to a Zero Trust model in which every access is independently evaluated.

In the Zero Trust model, security is predicated on an accurate evaluation of what should be permitted within every access request. Initially, it was considered sufficient for enterprise services to evaluate the validity of a session cookie, or access token, associated with each web and API request. 

However, this approach has left a few gaps:

• What if an organization wants to instantaneously revoke all access granted to a person or agent due to an urgent event (such as an employee getting terminated, or rogue agent activity)?
• What happens if the factors that went into the decision to issue the access token or cookie in the first place change dynamically while the token or cookie hasn’t expired?
• What happens if the scope of access represented by the token or cookie changes after the token was issued?

To take care of this, organizations often consider two strategies:

• Keep the token short-lived
• Re-validate the token at every request

Neither strategy is ideal. If a token is used, say, a thousand times on average (an extremely conservative estimate for a 24-hour token), then the “re-validate at every access” strategy places a 1000x burden on the issuing system (typically the identity provider, or IdP). This approach is usually considered technically unviable.

The “short-lived token,” on the other hand, places only a roughly 24x burden (assuming one goes to a token that lives for an hour instead of 24 hours), depending on how short-lived the token is. But the short-lived token severely degrades user experience, even if all the user must do is redirect to the IdP and back when the token expires.

Then how can one react based on changes that affect access properties while the access token is still valid?

The Continuous Authorization Conundrum

Let’s take a look at how a system determines whether a token is valid or not. It needs to evaluate multiple factors, such as:

• Is the user or agent account represented by the token valid?
• Is the access still from a device that has no security incidents associated with it?
• Is the accessing device still compliant with device management policies?
• Have the user’s or agent’s tasks changed such that they no longer need the same scope of access offered by the token?
• Has the user gone on leave? Have they gone off duty? Has the agent been terminated?

If we do not want to call the IdP for every access, then we need to evaluate this information at the service the user is accessing, at the time of access, and within milliseconds, so the user doesn’t find a degraded experience.

The problem is, all of this data is located in different places. The user’s account information is in a directory at the identity provider or on-premises. The device security incidents are known to the extended detection and response (XDR) system. The device compliance data is with the MDM. The task information is in a task tracking system such as ServiceNow or Jira. The leave information is in the HR system. The on-duty schedule is in a scheduling system such as PagerDuty.

This brings us to the continuous authorization conundrum:

Solving the Conundrum

While evaluating all needed information in real time at the time of access would seem like a virtually impossible task, a well-established pattern can make it possible. The resulting architecture is arguably more robust and secure than before. In practice, this evaluation happens at a policy enforcement point, which can be externalized from the application, rather than the application code itself.

The solution principles are to:

• Asynchronously and reliably deliver any changes in data required to make access decisions to the system that requires them.
• Evaluate every access request based on the data that is locally available.

A challenge in implementing this architecture is that every system that holds such data could belong to a different provider, and updating each party’s data asynchronously at every other party that requires it will be extremely challenging.

Standards to the Rescue

This is where open standards come into play. The OpenID Foundation has, over a span of 6+ years, developed the Shared Signals Framework (SSF). SSF provides a reliable, asynchronous mechanism to deliver discrete packets of information called Security Event Tokens (SETs). SETs are a standard developed by the IETF. The reliable delivery is important here because SSF transmitters and receivers both know which events have been correctly transmitted to which receiver. SETs are JWTs signed by SSF transmitters and are verified by SSF receivers. ​Because signals are delivered asynchronously, propagation is near real time rather than instantaneous.

Based on SSF, the Continuous Access Evaluation Profile (CAEP) has defined events that communicate changes required to modulate access in real time. These include:

• Session revoked
• Device compliance change
• Credential change
• Risk level change

There are other profiles based on SSF, such as Risk Incident Sharing and Coordination (RISC), used for communicating account security events, and SCIM Events (used for communicating account changes).

Systems implementing SSF exchange these events so the required data is available to any trusted party that needs it to make near real time access decisions. This is an essential component of implementing a true Zero Trust architecture.

Adoption

SSF and CAEP are being widely adopted across the industry. Popular technology providers such as Apple, CrowdStrike, Google, IBM, Jamf, Okta, SailPoint, Zscaler, and others have all implemented these standards in their products.

Recently, CrowdStrike and Zscaler demonstrated Zero Trust access based on SSF and CAEP, where access to cloud services through Zscaler is determined in near real time by CAEP events based on device incidents detected by CrowdStrike. Read the blog post (which also includes a video demo) here.

The same shared-signals foundation applies as AI agents take on privileged tasks: their access must also react to changing conditions in real time. 

Ask your security and identity vendors, SaaS providers, cloud providers, and MSPs about SSF and CAEP support, and how they participate in the signals ecosystem.