Replies: 1 comment
-
Given the complexity of this issue, it is a query that falls within the realms of commercial support. Are you one of my customers? If so, please do reach out directly to me and I'll be happy to start a discussion! My email address is [email protected]. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Good morning,
We need information about taking into account with APIMAN Authentication Digest.
Context: We have data providers who expose their data in Digest Authent (with the Tomcat servlet engine).
However this doesn't work.
Preamble :
Please note (because it is essential to understand the analysis): the client values “digestURI” for this calculation thanks to the endpoint. In other words everything that comes after the server:port/DNS.
For example :
so DigestUri = /response-ws-webapp/services/WS resource
so digestURI= /organization/api/version api/response-ws-webapp/services/WS resource
• When the server receives the second call, it repeats the calculation that the client did and if its result for “response” is the same as the one that the client sent it,
it validates the authentication, otherwise returns a 401 error
Let's keep this preamble in mind to move on to the analysis.
Let us also specify that 2 settings are involved in the overall behavior:
• rewriting the uri by APIMAN: rewrite_URI
• validation of the uri by DIGEST: validateuri
What we observed:
The reason for the KO is the rewriting of the URI by APIMAN. As stated in the preamble, the client takes the URI of the endpoint and therefore,
in the APIMAN context, uri =/organization/api/api version/response-ws-webapp/services/WS resource for client-side calculation
On the other hand, as the server receives in the uri, following the rewriting, the value "/reponse-ws-webapp/services/resource of WS",
the response calculation necessarily gives a different result.
Nothing to do with the valuation of the DIGEST validator parameter
Rewriting the Uri is an invalid solution, because the client and server must use the same values to calculate the header responses
and it is not possible to influence how Digest, on the client side, extracts this value from the endpoint.
The APIMAN endpoint would have to be "https://portail-apiman/organization/api/version api/reponse-ws-webapp/services/ressource du WS" which is not possible because APIMAN must be able to differentiate between environments.
This also implies having to set the validator to false in DIGEST, which could lead to other problems.
Can you please enlighten us on this subject and possibly give us some feedback?
THANKS,
Sincerely,
Beta Was this translation helpful? Give feedback.
All reactions