4.1.7 - Real time access control decision making (ed note: initially became 4.1.6)

[EnigmaRosa]

Note: this is referenced as 4.1.10 in #2033, but I updating the numbering to account for the skipped requirements.

Ed note: This is being merged as 4.1.6

I propose the addition of a new requirement that addresses the need for access decisions to be made on the most current permissions information. For example, let's say a user's access permissions are modified while that user has an active session (i.e. admin revokes access to edit files) - if the system does not check the user's permissions in real time (i.e. instead relying on cached access information), the user would be able to edit a file, which they should no longer be able to do.

#	Description	L1	L2	L3	CWE
4.1.7	[ADDED] Verify that the access control system makes real-time access control decisions based on current permissions values.	✓	✓	✓

[elarlang]

We have a requirement

#	Description	L1	L2	L3	CWE	NIST §
3.5.7	[ADDED] Verify that all active stateless tokens, which are being relied upon for access control decisions, are revoked when admins change the entitlements or roles of the user.	✓	✓	✓	613

I have proposed to move it to access control in #1917

We don't have a matching requirement for the same situation in the "classical session management" - if the permissions for the user are changed, it must have immediate effect. Such as in case those are buffered to session data, those also must be "revoked".

So maybe we need to make this requirement to cover both situations and to be more abstract. Or do we need to have another requirement for "classical session management".

It may make sense to read the issue, as there are other related comments, but let's continue the discussion in this issue.

[jmanico]

Note: revoking the token is pretty dramatic. I'd rather set up a rule with the new access control policy for that user (using some caching method) so the user experience is not effected. If you can revoke an active token, then having a "access control over-ride" list is just as easy.

[randomstuff]

Verify that all active stateless tokens

Apparently (today I learned), the blessed lingo for that would be/become "self-encoded tokens"?

[tghosth]

So we currently have two proposals.

I prefer @EnigmaRosa's requirement above #2059 (comment), because it is more outcomes focused than implementation focused. However, I think we do also need to address the token based situation as well.

I would propose something like:

#	Description	L1	L2	L3	CWE
4.1.7	[ADDED] Verify that the access control system makes real-time access control decisions based on current permissions values. Where the application is relying on roles and entitlements from a signed token, it will be necessary to either rotate this token when permissions change or ensure the token only has a very short lifetime.	✓	✓	✓

What do we think?

[elarlang]

This is a quite weird requirement by wording - "You must do it immediately, ... or a bit later is also ok."

What do you mean by "rotate the token" - from the OAuth perspective - is the requirement addressing refresh token's or access tokens? What means "very short lifetime"?

It overlaps with V3 stateful vs stateless and with OAuth topics. I think we need to find more general solution here than writing "if stateless" to each requirement.

[randomstuff]

What about something like "ensure that changes of roles and entitlement are taken into account in the policy enforcement points in at most X".

When using some kind of reference token which involves a request to a separate service for validation, you will probably end up using a small cache in order to avoid making the token validation request for each incoming request (based on the freshness of your last check and how critical the current request is).

When using a self-encoded token, this is going to be implemented by the short validity of the token.

[EnigmaRosa]

Really the question is if we want to go high-level or make sure to include classical and stateless

[tghosth]

This is a quite weird requirement by wording - "You must do it immediately, ... or a bit later is also ok."

I can accept that, on the other hand, I don't want to overthink this too much.

Really the question is if we want to go high-level or make sure to include classical and stateless

In principle, I want to keep things high level.

On the other hand, in a system where the permissions mechanism relies on signed tokens, is it possible to comply with this requirement?

Maybe the solution is to either allow a grace period or make this an L2 or L3 requirement.

What do people think?

[randomstuff]

Maybe the solution is to either allow a grace period or make this an L2 or L3 requirement.

Yes, in practice for scalability reasons, you are often going to have some small grace period between the moment you modify some user permissions and the moment the modification is actually taken into account (especially in highly distributed and high-availability systems).

Some examples:

If you are using some OIDC user claims for authorization decision and you want real-time access control decision, you are going to need to be a UserInfo request for each incoming request. (Another solution would be to rely on Shared Signals).

If you are using OAuth access tokens and you want real-time access control decision, the resource server is going to need to check the status of the access token (using token introspection) for each incoming request.

Another case is if you are storing the user permissions in a database which features eventual consistency for high availability.

Google's Zanzibar is certainly a well-designed scalable system for this topic. However it does not feature real-time access control decision (in this sense) but only features external consistency:

Zanzibar’s external consistency model is one of its most salient features. It respects the ordering of user actions, yet
at the same time allows authorization checks to be evaluated at distributed locations without global synchronization

[EnigmaRosa]

I'm good with making this L2 & L3

[tghosth]

Updated proposal. I have made this Level 2 and have reworded to try and focus on the problem. @elarlang is ok with it.

What do you think @jmanico @EnigmaRosa?

#	Description	L1	L2	L3	CWE
4.1.7	[ADDED] Verify that permissions values on which access control decisions are made, are updated as fast as possible. Where this is longer than a few minutes, it will be necessary to implement migrating controls to alert when a user performs an action when they should no longer be able to do so.		✓	✓

[jmanico]

A few suggestions:

Verify permission values used in access control decisions are updated in real-time or as quickly as possible. If updates exceed a few minutes, implement monitoring and alerts to detect and block unauthorized actions. Invalidate stale permissions promptly and refresh cached permissions regularly.

[elarlang]

The requirement here should only be about V4 authorization. One thing per requirement.

[jmanico]

Fair point. I suggest we just keep is simple then.

Verify permission values used in access control decisions are updated in real-time.

[elarlang]

Also, I recommend thinking about and defining, what "real time" means.

Let's say we have a "classical" server-side session, session token/id delivered in a cookie - if there is a permission change, account termination, etc - "real-time" means that in the very next second this user is logged out from the UI, and not waiting for the next request to the server. So it requires sockets to keep it "real-time".

[jmanico]

That's fair. How about back to:

Verify permission values used in access control decisions are updated in real-time or as quickly as possible

[tghosth]

@elarlang

The requirement here should only be about V4 authorization. One thing per requirement.

Are you talking about "If updates exceed a few minutes, implement monitoring and alerts to detect and block unauthorized actions."

If so, I think that this is an important mitigating control which is why I added it as there are a lot of reasons why "immediate" is not possible.

Let's say we have a "classical" server-side session, session token/id delivered in a cookie - if there is a permission change, account termination, etc - "real-time" means that in the very next second this user is logged out from the UI, and not waiting for the next request to the server. So it requires sockets to keep it "real-time".

I think the implication is that the next time the user attempts to refresh data it will no longer be accessible. I don't think we can handle a situation where they have just left the screen open. That is what idle timeout is for :)

---

I also feel like the "real time" phrase is causing problems.

I would suggest:

Verify that permission values used in access control decisions are updated immediately or as quickly as possible.

[EnigmaRosa]

I feel like the "as quickly as possible" language is going to be a problem. I understand why we select that phrase, I'm just concerned users will have issues with it.

[tghosth]

I feel like the "as quickly as possible" language is going to be a problem. I understand why we select that phrase, I'm just concerned users will have issues with it.

I agree it is not ideal but I think real time is also a little relative :) Any thoughts on different wording?

[randomstuff]

real time

Actually, the definition of "real-time" is that the delay must be bounded by some specified value, so if we wanted to paraphrase the meaning of this, it would be:

Verify permission values used in access control decisions are updated as quickly as possible and within a documented bound constraint defined according to the security requirements of the application. This time constraint may vary depending on the action to authorize and must be lower than XXX.

[tghosth]

Feels like we are back to my previous proposal: #2059 (comment)

This proposal provides some practical bounds for what "as fast as possible" means as well as a practical mitigation. I think the second sentence is clearly relevant to the first sentence as a direct follow-on/consequence.

#	Description	L1	L2	L3	CWE
4.1.7	[ADDED] Verify that permissions values on which access control decisions are made, are updated as fast as possible. Where this is longer than a few minutes, it will be necessary to implement mitigating controls to alert when a user performs an action when they should no longer be able to do so.		✓	✓

[elarlang]

New bone to bite:

Verify that permissions values on which access control decisions are made (such as changes in user rights, roles, or account status) are effective immediately. There can be a maximum few minutes for changes to take effect for stateless tokens or synchronization issues, but then there must be a solution to monitor and revert changes that are made by the user after the permissions were changed to not allow that. Note that it is not possible to revert information leakage.

[tghosth]

Good point about information leakage.

Comparing "as fast as possible. Where this is longer than a few minutes," and "are effective immediately. There can be a maximum few minutes for changes to take effect", what do you specifically prefer about your wording?

[elarlang]

It's too much to say that I prefer my wording, it's just different, and the reason for not using "fast as possible" is that it is relative depending on solution, for someone "fast as possible" is 10 minutes maybe.

[tghosth]

It's too much to say that I prefer my wording, it's just different, and the reason for not using "fast as possible" is that it is relative depending on solution, for someone "fast as possible" is 10 minutes maybe.

Ok but I also qualify with "more than a few minutes" which hopefully makes it less relative

[elarlang]

Maybe we take the time out from this, for the direction:

Verify that permissions values on which access control decisions are made (such as changes in user rights, roles, or account status) are effective immediately. If permission changes are not effective immediately then there must be a solution to monitor and revert changes that are made by the user after the permissions were changed to not allow that. Note that it is not possible to revert information leakage.

But we should mention the stateless token struggle there more clearly to cover current requirement:

V3.5.7 Verify that all active stateless tokens, which are being relied upon for access control decisions, are revoked when admins change the entitlements or roles of the user.

[tghosth]

Ok so how about:

#	Description	L1	L2	L3	CWE
4.1.7	[ADDED] Verify that values on which access control decisions are made, are updated immediately. Where values cannot be updated immediately, there must be mitigating controls to alert when a user performs an action when they should no longer be able to do so, and revert the change. Note that this would be unable to mitigate information leakage.		✓	✓

But we should mention the stateless token struggle there more clearly to cover current requirement:

Sorry I didn't understand your point

[elarlang]

Sorry I didn't understand your point

All this Where values cannot be updated immediately part is basically meant for stateless tokens solutions, but it's not that clearly highlighted.

From the first part you ignored my update proposal, and it's not clear, for whom/what the "immediate update" must be done.

[tghosth]

Final proposal discussed with @elarlang.

#	Description	L1	L2	L3	CWE
4.1.7	[ADDED] Verify that changes to values on which access control decisions are made, are applied immediately. Where changes cannot be applied immediately, (such as when relying on data in cryptographically secured tokens), there must be mitigating controls to alert when a user performs an action when they should no longer be able to do so, and revert the change. Note that this would be unable to mitigate information leakage.		✓	✓

This should supersede 3.5.7 as a a more goal focused requirement.

@set-reminder @tghosth to open PR in 1 hour

[octo-reminder]

⏰ Reminder
Thursday, October 31, 2024 1:35 PM (GMT+01:00)

@tghosth to open PR in

[octo-reminder]

🔔 @tghosth

@tghosth to open PR in

[tghosth]

PR opened (requirement is 4.1.6), #2210