Quarkus: Trace keycloak calls

[dcdh]

Description

In Quarkus we can log all requests using opentracing feature. However it is not the case about requests made by the authentication mechanism using keycloak.
It would be nice to add them in opentracing because keycloak can be a point of failure. Also it may be useful to collect response time to analyze them afterwards.

Implementation ideas
quarkus-keycloak-authorization used VertX VertxHttpFacade to make calls. VertX web seems to be also used by rest endpoint. So maybe that we could add TraceId, SpanId into VertxHttpFacade ? (It is a suggestion) by using the same traceId used from the rest call.

Some implementations on how to add trace feature for Vertx web can be found in this project:

        <dependency>
            <groupId>io.opentracing.contrib</groupId>
            <artifactId>opentracing-vertx-web</artifactId>
            <version>1.0.0</version>
        </dependency>

[quarkusbot]

/cc @kenfinnigan, @Ladicek

[Ladicek]

This makes a lot of sense to me, Keycloak calls should definitely be visible in the trace.

[Ladicek]

On the other hand, I have no idea who would be the best person to deal with this :-) CC @sberyozkin @pedroigor

[Ladicek]

And CC @pavolloffay

[sberyozkin]

I'm not sure about exposing the trace calls to the underlying providers (OIDC, etc) which secure Quarkus endpoints, keycloak-authorization is only one case, tokens can also be introspected remotely against Keycloak (or Auth0 etc), etc. And it provides a bit too much information to the users as I guess they want to see the open traces without having to authenticate ? CC @pedroigor

[pavolloffay]

+1 to trace the requests to keycoak the opentracing-vertx-web creates standard HTTP span with URL, verb, status code. It could be also possible to add other tags that might be unique to keycloak and give value from the observability standpoint.

One thing to look after is to make sure that spans created by the vertex client are connected to the parent transaction.

[pedroigor]

I lack experience in this area but I would expect to have a generic solution that would allow tracing not only keycloak-authorization calls but also quarkus-oidc (I think @sberyozkin highlighted this).

[sberyozkin]

Hi @pedroigor yeah, well, I was again being a bit paranoid here :-), suggesting that exposing the KC traces to a Quarkus endpoint user is the info which is arguably sensitive - shows the traget address of the OIDC server which is outside of the scope of tracing the application specific calls through the distributed system.
That said, if it is configurable (ex, block exposing these traces if needed) then may be it is all right. CC @stuartwdouglas as well

[stuartwdouglas]

I don't see any problems with this, but obviously things like tokens and other credentials should not be included in the data.