Request for split(<separator>) operator

[jeffsec-aws]

While dealing with OAuth2 tokens, the scope claim (sometimes scp for some non-compliant OIDC providers) is composed of:

The value of the scope claim is a JSON string containing a space-separated list of scopes associated with the token, in the format described in Section 3.3 of [RFC6749].

Reference: RFC8693

The value of the scope parameter is expressed as a list of space-
delimited, case-sensitive strings. The strings are defined by the
authorization server. If the value contains multiple space-delimited
strings, their order does not matter, and each string adds an
additional access range to the requested scope.

Reference: RFC6749 / Section 3.3

A policy having multiple conditions using the like operator can be a solution:

permit(
  principal,
  action,
  resource
) when {
  context.token.scope like "*ScopeA*" &&
  context.token.scope like "*ScopeB*"
};

It won't be secure if the scope value is ScopeAScopeB with no space delimiter.

While a policy including the proposed split(separator) operator, it will be more secure:

permit(
  principal,
  action,
  resource
) when {
  context.token.scope.split(" ").containsAll(["ScopeA", "ScopeB"])
};

[shaobo-he-aws]

Thank you for your interest, @jeffsec-aws. I have a quick question. Is it possible to preprocess the data before authorization? For instance, the scope field can be a set of strings instead of a string. So, the policy becomes,

permit(
  principal,
  action,
  resource
) when {
  context.token.scope.containsAll(["ScopeA", "ScopeB"])
};

When constructing the context, you convert the scope claim into a set of strings (e.g., by calling the string splitting function of the language you like).

[khieta]

Another path forward here might be a "Path" extension, as proposed by @D-McAdams on this thread. The constructor for a "Path" could take the delimiter (in this case a space) as input, and support containsAll/containsAny methods.

[jeffsec-aws]

@shaobo-he-aws yes pre-processing is an alternative, but it means that the PEP touches the data submitted for authorization.

Having a split operator allows 3rd party Cedar oriented PDP that can consume OAuth2 tokens natively to work with the JWS natively and benefit from the digital signature protection against tampering while evaluating policies.

I understand this is niche.