Support for principal.id resolution in conditions

[identitymonk]

We have done an Interop activity with the OpenID Foundation AuthZEN Working Group and found an interesting case. Due to backward compatibility with other version of the specification, the Principal now has 2 different EntityTypes to describe it: user and identity.

If we want to forbid one principal to perform actions, we are forced to define the following policy:

forbid (
    principal,
    action,
    resource
) when {
 principal == user::"CiRmZDA2MTRkMy1jMzlhLTQ3ODEtYjdiZC04Yjk2ZjVhNTEwMGQSBWxvY2Fs" ||
 principal == identity::"CiRmZDA2MTRkMy1jMzlhLTQ3ODEtYjdiZC04Yjk2ZjVhNTEwMGQSBWxvY2Fs"
};

It will be easier and more natural if we could author the following policy:

forbid (
    principal,
    action,
    resource
) when {
 principal.id == "CiRmZDA2MTRkMy1jMzlhLTQ3ODEtYjdiZC04Yjk2ZjVhNTEwMGQSBWxvY2Fs" 
};

While I can understand the potential for disruptions by not mentioning the EntityType, if we follow the best practices, the ID should be an immutable unique id and therefore should allow to disambiguate any situation.

[identitymonk]

This can be useful if one has multiple applications that did use multiple schema definitions but want to put guardrails that are applied to the whole ecosystem.

[shaobo-he-aws]

Thank you for your interest in Cedar. IMO, the example is not very convincing if these forbid policies are automatically generated. In other words, we should be able to easily change whatever way used to add disjunctions. Furthermore, having this functionality will make wildcard matching on EntityUIDs possible, which is an anti-pattern.

[cdisselkoen]

For more on the idea of wildcard matching on EntityUIDs and why it's an anti-pattern, see the discussion here. (I recognize that the particular motivating example in this thread doesn't involve wildcard matching on ids, but the proposed fix would enable wildcard matching on ids.)