Sorry for the delay.
Internally, the Role membership determination uses a document reference (for a document, index, etc.). Using
Singleton adds a layer of abstraction that the Role logic is unable to penetrate. The conclusion is that you’re not going to be able to make this work with tokens. To continue with your approach, you’d have to use a key with the
That all seems correct.
When using a token to run a query, even if no Role provides any other access,
CurrentToken returns the reference to the current token. Fetching the document associated with that reference requires a granted privilege.
Role privileges are not transitive: you could grant read permissions to
Tokens() which is the internal collection containing Token document, but that doesn’t provide read access to all Token documents; it would be a potential security issue if it did.
So, a UDF that has higher privileges than the identity making the call, and granting permission to call that UDF, are required steps.
That is distinct from the
Singleton problem, where the identity document is, essentially, disconnected from Role membership.
CurrentIdentity returns the reference to the current identity document, which might be more straightforward than using
CurrentToken, depending on your use case.