Open APIs

 View Only
Back to discussions
Expand all | Collapse all

Question regarding RFC 7386 and field-level security

  • 1.  Question regarding RFC 7386 and field-level security

    Posted Aug 26, 2024 05:16

    Hello everyone,

    I would like to raise important question related to field-level security and its impact on RFC7386 (JSON Merge Patch).

    My understanding is so that RFC7386 proposes to patch arrays (collections) as a whole (overwriting previous value).

    We used to this behaviour and made our channels using TMF APIs sending all elements of nested collection to the backend event if just a single property was updated.

    Now we want to apply field level security on the backend serving TMF APIs and facing the following issue - if we filter out some fields belonging to an element of some nested array/collection (e.g. some attributes of contact medium or identification in customer management API) and don't send them in the response to the consumer, then consumer using this data as a basis for patch operation will unintentionally overwrite them with null values (de-facto corrupting backend data).

    Is there any recommendation on how to handle such an issue?

    P.S. I was trying to find something about the subject but wasn't able, so if is was already discussed, please, point me to the topic.



    ------------------------------
    Boris Khatkov
    Principal Solution Architect, R&D
    Netcracker Technology
    ------------------------------


  • 2.  RE: Question regarding RFC 7386 and field-level security

    Posted Aug 27, 2024 04:26

    Hi Boris,

    RFC7386 (JSON Merge Patch) is not very suitable for merging complex entities with nested collections. It is intended for simple operations like status updates or adding timestamps.

    RFC6902 (JSON Patch) already provides more flexibility and "TMF630 REST API Design Guidelines Part 5 (JSON Patch extension to manage arrays) provides extensions that help for your use case. You will be able to find reference implementations of this extension on the internet.

    Regards



    ------------------------------
    Koen Peeters
    OryxGateway FZ LLC
    ------------------------------



  • 3.  RE: Question regarding RFC 7386 and field-level security

    Posted Aug 28, 2024 04:32
    Edited by Konstantin Tarasov Aug 28, 2024 04:35

    Hi Koen,

    RFC7386 (JSON Merge Patch) MUST be supported according to TMF API Specifications regardless of complexity of the model (Quote, Customer and so on). 



    ------------------------------
    Konstantin Tarasov 
    ------------------------------

    Original Message


  • 4.  RE: Question regarding RFC 7386 and field-level security

    Posted Aug 28, 2024 09:09

    Hello Koen,

    Konstantin is right. RFC7386 is mandatory according to the specifications, hence, we have to support it and our consumers must be able to use it. So, the question is still open.



    ------------------------------
    Boris Khatkov
    Principal Solution Architect, R&D
    Netcracker Technology
    ------------------------------

    Original Message


  • 5.  RE: Question regarding RFC 7386 and field-level security

    Posted Aug 30, 2024 00:03

    @Boris Khatkov states: "RFC7386 is mandatory according to the specifications".  Could you provide a citation?  What specification makes merge patch mandatory? Is it required in any CTK?



    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------

    Original Message


  • 6.  RE: Question regarding RFC 7386 and field-level security

    Posted Aug 30, 2024 02:58
    Edited by Konstantin Tarasov Aug 30, 2024 02:58

    E.g. in Quote 648 API Specification:

    The same is stated in all others API Specification documents.

    ------------------------------
    Konstantin Tarasov
    Netcracker Technology
    ------------------------------

    Original Message


  • 7.  RE: Question regarding RFC 7386 and field-level security

    Posted Aug 30, 2024 06:56

    Hi,

    Merge-patch only provides a solution for deleting attributes by providing a null value. However it doesn't provide a solution for manipulating arrays/collections other then provide the full array.

    So I fear there is no standard solution to your problem of securing individual fields. 



    ------------------------------
    Koen Peeters
    OryxGateway FZ LLC
    ------------------------------

    Original Message


  • 8.  RE: Question regarding RFC 7386 and field-level security

    Posted Aug 30, 2024 07:18
    Edited by Boris Khatkov Aug 30, 2024 07:48

    Hi,

    That is what I meant. There is no standard solution within either of these 2 RFCs.

    However, there are a lot of examples of how others solve the issue.

    For example, if I remember Kubernetes API introduced additional collection merging functionality on top of RFC7386 (that merges item by item) and allow to pass the flag to enable this strategy in the API call.

    Should we have a look at that approach and include it in TMF APIs guidelines?

    I think that attribute level security is super essential requirement and deserves to be addressed in the guidelines.

    Refs to k8s docs:

    https://kubernetes.io/docs/reference/using-api/api-concepts/#patch-and-apply

    https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/#use-a-json-merge-patch-to-update-a-deployment



    ------------------------------
    Boris Khatkov
    Principal Solution Architect, R&D
    Netcracker Technology
    ------------------------------

    Original Message


  • 9.  RE: Question regarding RFC 7386 and field-level security

    Posted Sep 02, 2024 01:28
    Edited by Vance Shipley Sep 02, 2024 01:28

    JSONPath (RFC9535) should play a role in any solution here as it properly addresses the key issue.

    Th exact problem you described is handled in TMF630 Part 6: JSONPath extensions.



    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------

    Original Message


  • 10.  RE: Question regarding RFC 7386 and field-level security

    Posted Sep 02, 2024 07:42
    Edited by Boris Khatkov Sep 02, 2024 07:43

    Hi Vance,

    Unfortunately part 6 of TMF630 doesn't suggest any resolution for our problem apart from switching to another RFC5789 and usage of JSON paths inside its model. Switching to another RFC would anyway mean that we break requirements re support of RFC7386. Kubernetes's approach for resolution of absolutely the same issue is much better as it doesn't suggest us to rewrite all existing client code to the new model breaking backward compatibility.



    ------------------------------
    Boris Khatkov
    Principal Solution Architect, R&D
    Netcracker Technology
    ------------------------------

    Original Message


  • 11.  RE: Question regarding RFC 7386 and field-level security

    Posted Sep 02, 2024 01:21

    Right, I had forgotten about this.  My interpretation, and my opinion has zero authority, is that we should support simple patch in simple cases (only).



    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------

    Original Message


  • 12.  RE: Question regarding RFC 7386 and field-level security

    Posted Sep 03, 2024 05:34
    Edited by Yurii Yushchak Sep 03, 2024 05:49

    Hi,

    RFC7386 (obsoleted by RFC7396, but still) contains restrictions that are explicitly stated in the RFC text.

    There are a few things to note about the function.  If the patch is
anything other than an object, the result will always be to replace
the entire target with the entire patch.  Also, it is not possible to
patch part of a target that is not an object, such as to replace just
some of the values in an array.

    Therefore, you are trying to use RFC7386 for the use case that this RFC is not intended for.

    As for the sentence "Support of json/merge (https://tools.ietf.org/html/rfc7386) is mandatory, support of json/patch (http://tools.ietf.org/html/rfc5789) is optional." in the TMF APIs specifications, I would interpret it to mean that TMF fully supports RFC7386 json/merge, but if RFC7386 restrictions do not allow you to achieve your goal, you can also use RFC5789 json/patch.



    ------------------------------
    Yurii Yushchak
    System Manager
    Ericsson Inc.
    ------------------------------



Related Content