4.1.7 - Real time access control decision making

[EnigmaRosa]

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

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