Enterprises relying on on-premise or cloud identity providers (IdPs) to authenticate users to third-party SaaS apps or internal apps are often challenged with implementing effective access control or authorization.
By relying on techniques like RBAC and ABAC, privileges usually proliferate well beyond what any user needs at any point in time. This provides an opportunity for a growing category of compromise, which relies on authenticated users abusing their access privileges to exfiltrate, modify or erase critical data.
The authenticated user may represent a negligent or malicious insider or an attacker who has hijacked an insider’s credential or session.
Just-in-Time Access
A new way of implementing enterprise authorization is to enable access to individual assets (e.g., a specific customer record or an invoice) by determining the permissions just in time when a user needs to perform such access and to revert those permissions immediately after the user’s task is completed.
By relying on typical workflow or ticketing systems such as ITSM or CSM, one can determine when a user’s access to a specific asset is justified. This justification is then propagated in the form of specific permission tuples to the SaaS or internal apps where the access control is enforced.
This approach has multiple benefits:
- Enterprises do not have to propagate static group information across 3P SaaS and various directories for apps to enforce authorization controls
- It reduces an enterprise’s reliance on static roles, which are hard to adapt to an organizational structure that keeps changing dynamically — think person X is temporarily assigned to help out team Y and so must access team Y’s data.
- It brings enterprises closer to the principle of least privilege access by dynamically enabling the right person to access the right data at the right time in the right app.
- Some recent high-profile compromises (e.g., Okta) could have been mitigated using Just-in-Time Access by preventing the compromised endpoint from being able to access such a large set of data.
Leveraging OpenID Standards
So how can such just-in-time permission information be propagated? This is where the OpenID standards of SSE and CAEP come into play. The Continuous Access Evaluation Protocol (CAEP) was first proposed by this author when he worked at Google. It has since merged into an existing working group in the OpenID foundation, which used similar mechanisms to solve a related problem of account compromise.
The resulting Shared Signals and Events (SSE) Framework is now a generic framework for implementing secure, privacy-protected webhooks for any API. It is leveraged by both the CAEP and RISC standards. Both these standards are hugely successful; they are in production use by Google and Microsoft for some of their busiest services.
Using CAEP for Just-in-Time Access
Applications often receive permission information as claims in OIDC tokens. The Continuous Access Evaluation Profile of the SSE Framework (retaining the same acronym CAEP) defines an event named “token claims change.” To implement Just-in-Time access, the initial OIDC token may not contain any permission claims, or may contain permissions claims that name specific assets such as customer IDs. When, for example, a customer support employee is assigned to work on a case that relates to a specific customer, a service monitoring such changes can send a CAEP token-claims-change event that modifies the permissions claims to include the specific customer Id to which the case relates. Once the case is closed, the monitoring service sends another CAEP token-claims-change event that removes the user from having access to that customer.
The app then simply has to verify if an incoming user has the permission required to access a specific asset. The app can store this permission information with the asset in question and update this information in response to the CAEP messages it receives.
An example CAEP event is here:
{
"iss": … // standard JWT fields here.
"events": { // this is the field defined by SSE
"https://schemas.openid.net…<strong>token-claims-change</strong>": {
"subject": {
"format": "email",
"email": "jane_in_support@mycompany.com"
},
"event_timestamp": 1615304991643,
"claims": {
"customer_id": "C2148",
"access_allowed": "read_write" // or "none" to remove
}
}
}
}
In the example above, the CAEP event enables the user “Jane in Support” read-write access to the specified customer. In response to receiving this event, the app can provide read-write access to Jane for the specified customer. Conversely, when Jane in Support has completed their task and closed the case, the CAEP event disables their access to the specified customer, providing a powerful way to control access in a zero-trust environment.
Coexisting with RBAC
If your app already implements group-based authorization, then Just-in-Time Access can coexist with such existing controls. This can be achieved in two ways:
- An app may offer Just-in-Time Access capability to critical assets, such as specific sensitive customer accounts, whereas other assets continue to rely on RBAC for coarse-grained permissions. Doing so enables the app to keep the Just-in-Time Access information separate from RBAC information.
- Specific assets can be switched to using dynamic groups that are populated and unpopulated in response to CAEP messages. This strategy may work better if the app will continue to use group-based access control in the future.
Summary
- RBAC and ABAC haven’t been effective in containing privilege sprawl but in fact have contributed to it.
- Just-in-Time Access Management (JAM) is a step forward in simplifying fine-grained authorization in enterprises.
- Standards such as OpenID SSE and CAEP can help propagate required information to 3P SaaS apps.
- Just-in-Time Access Management can complement existing RBAC implementations, providing finer-grained access control and potentially mitigating the impact of compromises.