[Federation] Policy operator processing order and consistency

[Stefan Santesson]

This is the last one I have in my backlog of issues.

I would propose an easier and more fault tolerant approach to policy operator consistency as well as processing order.

The problem currently is that it is very hard to ensure policy operator consistency using a particular processing order. The simple reason being that what is modified or checked by one policy operator, can be modified by a later modifier in the order.

‌

I would therefore suggest a simpler and more fault tolerant strategy. Processing policy operators in two distinct steps:

Step 1 (Apply all modifiers)

This step process any policy operator that have any potential to change the metadata value. This process must start with “value”, “add” and “default” in that order. The rest of the modifiers can be processed in any following order, including any custom modifiers not in the current specification.

Step 2 (Validate modified metadata)

In this step, the metadata value that is output of step 1 is validated against all policy operators (modifiers and value checks)

No modifications of the metadata value is allowed in this step.

If any policy operator is inconsistent with the metadata value, this check fails and metadata is invalid.

‌

This process could replace the procedure outlined in 5.1.5, but it could also allow deletion of 5.1.3 as the rules in 5.1.3 are automatically enforced in Step 2. An alternative is to explain that the rules of 5.1.3 are automatically enforced and make it more informative in nature. e.g. say that “Some combinations of policy operators will fail policy processing. Examples of such invalid combinations are:”

This proposed processing strategy will change the outcome in some cases. For example in the current document processing stops if “value” is set. In the proposed processing “value” will fail if it is inconsistent with other policy operators. I think it should fail.

[Stefan Santesson]

I wrote this issue based on draft 30

Just adding that the updated section 5.1.4 in draft 31 does not work unless the policy is enforced to be compliant with rules of 5.1.2 are checked and enforced before being processed. This should be clarified in 5.1.4 if the ordered strategy is applied.

The operator “subset_of” for example may alter the metadata in violation of the “add” modifier. Unless the consistency check is made properly, this will go unnoticed and create metadata in conflict with the policy.

One worry here is also that policies that are consistent in their own right, can create errors when combined in the merge process (se separate issue).

Having a verification step after modification would still be safer compared to the order in draft 31.

‌

[Vladimir Dzhuvinov]

[Federation] tag in title

[Michael Jones]

This seems to overlap with issue #2087. They should probably be addressed together.

[Stefan Santesson]

I think this one is valid even if we close #2087

I think the logic of the standard can be significantly simplified by simply applying policies in the order suggested here. If you do that you don’t have to do any consistency checks. If the policy rules are not consistent, they will fail anyway.

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/718