Need a way to set http headers from Java Client API #767
Comments
|
@tdiepenbrock I'm curious how committed you are to this solution or if we might be able to explore different ways to properly address these use cases. In general, the Java Client API strives to expose straight-forward functionality while abstracting away the implementation. Of course no abstraction is perfect, and we'll have to make exceptions. However, with HTTP/2 fast gaining traction, we're reminded that even widely-accepted foundations like HTTP can be shaken. So the more we tie ourselves to our current HTTP implementation, the more we'll struggle to change that implementation without deprecating important parts of the API. Additionally, we're currently replacing our core HTTP library, Jersey, with OkHttp. This process has made it clear that we exposed too much HTTP functionality as not everything implemented in Jersey (which builds on HttpClient) is available via OkHttp. Therefore, to make this transition properly we're wrestling with how much implementation and QA burden to take on for work like SSL cert parsing which is not even core to our business. For the specific scenario of SSL Client Cert auth, I have a few concerns:
|
Sorry, I didn't address this part. This makes sense, since I'm familiar with your current approach. Would you recommend that other clients take your current approach? I'm thinking we might want to seek a more accessible path for broad adoption. Specifically, it makes sense that we need a solution for "application-level authentication" #766 and that solution needs to allow you a way to transmit any groups/roles and potentially other app-specific information as part of the auth request. Does that sound right? |
|
Ultimately I believe our goal is to support "application-level"
authentication--which I agree is becoming sort of a misnomer--via the Java
Client API. I see a few needs that are somewhat conflicting that are
complicating the overall issue. In the list below I say "we" to mean "we
as an organization/development community":
1) we have a high-priority need to support customers who want to send user
credential information to ML via the Java Client API for use in
application-level authentication.
2) we want to make a clean, maintainable implementation of this in the Java
Client API that won't be released and then deprecated soon after.
3) we want better server-side support for application-level authn for the
REST api.
4) we want to make an overall review of marklogic authn in general,
including the client API's, to make sure we have a cohesive approach across
the server product and the client APIs.
5) We are replacing the Jersey library, which complicates the client-side
part.
In essence 1) is a near-term need for an official GA release of the API and
the rest are part of a longer-term need to have a smooth integration of all
our different means of authentication/authorization. That line of
reasoning in our other email threads led us to this idea of providing a raw
header capability in the Java Client API (#767) to meet 1)'s short-term
need, and since it's a handy thing to have in general it seemed to make
sense, though the Jersey issue complicates things somewhat. Then we would
design/build a more cohesive solution to authn overall as a longer
design/implementation process.
td
Regarding the SSL Client Cert auth, the concern there is that we need to be
able to authenticate
…On Fri, Jul 7, 2017 at 11:01 AM, Sam Mefford ***@***.***> wrote:
In the short term, we need a way to set generic http headers via the Java
Client API. This is important because many of our customers are using
enterprise SSO systems where user credential information is returned via
HTTP headers. The username and any groups/roles are returned in specific
headers for different categories of roles, so we need to be able to
transmit this information to the server to use in application-level
authentication.
Sorry, I didn't address this part. This makes sense, since I'm familiar
with your current approach. Would you recommend that other clients take
your current approach? I'm thinking we might want to seek a more accessible
path for broad adoption. Specifically, it makes sense that we need a
solution for "application-level authentication" #766
<#766> and that
solution needs to allow you a way to transmit any groups/roles and
potentially other app-specific information as part of the auth request.
Does that sound right?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#767 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AH7cXTyEyiUck5QqP30iP5ZjD6JTDZi6ks5sLkhNgaJpZM4OQ6LU>
.
|
|
One small clarification: replacing Jersey doesn't complicate things from a design standpoint. It's just a use case to teach about the perils of exposing too much tied to the underlying implementation. The specific case is that we exposed DatabaseClientFactory.SSLHostnameVerifier.ANY, COMMON, and STRICT (based on org.apache.http.conn.ssl.*HostnameVerifier). The loose docs we had for them left them more or less tied to the vague semantics of the Apache HttpClient implementation. While they are useful in theory, they introduce a challenge as we move off Apache HttpClient. In this case of this RFE, the generic underlying implementation under discussion is HTTP. While that's not likely to change, we're wary of treating the Java Client API as an HTTP pass-thru, especially when the target are our supported REST endpoints. We need to be thoughtful about whether to expose something like this. So far we haven't needed to do it to achieve our goals. |
|
I believe the pressing need for this has gone away. Please re-open if I'm wrong. |
Related to issue #766.
In the short term, we need a way to set generic HTTP headers via the Java Client API. This is important because many of our customers are using enterprise SSO systems where user credential information is returned via HTTP headers. The username and any groups/roles are returned in specific headers for different categories of roles, so we need to be able to transmit this information to the server to use in application-level authentication.
Also this is important if we are using 2-way SSL for authentication. In the "old days" of J2EE, particularly Weblogic, servers that were behind a load balancer needed to authenticate the user via client certificate. The issue was that the load balancer would handle the initial SSL negotiation, so the certificate information was lost. The solution was to write a script for the load balancer to take the public certificate from the initial request and place it into headers where the Weblogic authenticators expected to find them, and then send the request to the server via plain HTTP. The authenticators would find the user certificate information they needed in the headers and authenticate the user. We could use exactly the same mechanism in MarkLogic if we had a generic HTTP header capability. This would be a huge benefit to our government customers, who tend to rely very heavily on 2-way SSL authentication.
Besides authentication, we could use HTTP headers to specify information that might be used by custom transforms—maybe a redaction method for the redaction API, for example, etc via a header. There are lots of uses for this sort of thing.
As for timing, my thinking is that this would be needed per-request. If the server is asking to set cookies, perhaps the Transaction class might be the place. There may be the need to override headers that the Client API may set itself--I'm not sure of all the headers the API sets (likely other customers won't either). But, when the situation arises where API is doing something (like setting a header) that breaks your application, we should provide a way for skilled developers to alter that behavior.
The text was updated successfully, but these errors were encountered: