Closed leonwanghui closed 5 years ago
This is actually something we're running into as well. The problem we're running into is that some requests are more system-generated than user-initiated - like GET /v2/catalog. We're still working on a proposal but our current thinking is that some system ID should be used in those cases.
Keep in mind though, even w/o this header the request is still required to have some kind of auth (even if just basic auth).
@duglin Sure, please ping me if you finish the proposal, thx!
on call we discussed that some requests are made by the platform and not a user in the normal sense. these cases include orphan mitigation and last operation polling.
do we have a concern that the broker's auth mechanism might prevent the platform from performing these operations?
does it make sense to reserve a general "platform" user name or to recommend using the user that is used in the basic auth broker linkage?
In our environment the broker can call back into the Platform to verify the id in the request (and its auth). We don't need it to be a reserved user/id and I'm not sure we could do that - it will probably always need to be platform specific.
I believe that the purpose of the X-Broker-API-Originating-Identity
header is to inform service brokers which end-user triggered a request. Since calls to fetch the catalog are sometimes not triggered by an end-user, then I think no X-Broker-API-Originating-Identity
header makes the most sense in this case. Let me know if anyone still disagrees - closing for now.
When I had a look at our OpenAPI doc, I found that not all requests contain
X-Broker-API-Originating-Identity
parameter (specifically GET request doesn't contain). So it confuses me if it is safe to expose GET request (currently we have two GET requests) to the public, and IMO authentication SHOULD be guranteed in all user requests to accomplish access controller.Just challenge me if you have any doubts : )