In our project, we would like to secure the Camunda API with UAA Authentication (so each request to /engine-rest needs to be authenticated). This seems to be working fine so far, the communication between the different A12 components works.
However, we are using external Camunda workers, which need to connect to the Camunda Server via HTTP. With the new setup, those requests need to be authenticated. We would like to use the UAA Rest Client on the worker side. We have it on the classpath anyway (for other reasons) and it would be nice to have support for the different UAA authentication types.
I have seen that the UAA Rest Client provides a Spring Bean of org.springframework.http.client.ClientHttpRequestInterceptor that can be used to add authentication to arbitrary HTTP requests. The Camunda Client however is not based on Spring, but on org.apache.http.client.HttpClient and requires a bean of type org.camunda.bpm.client.interceptor.ClientRequestInterceptor and does the whole HTTP Interceptor wiring internally.
I tried to create an implementation of that interface, that mirrors the behaviour of com.mgmtp.a12.uaa.client.rest.auth.internal.AuthorizationInterceptor, but the implementation is heavily based on com.mgmtp.a12.uaa.client.rest.auth.AuthenticationHandler. It seems that this is only used internally in the UAA client, because I did not find an implementation, that is publicly available. I am able to implement the functionality i need, but that result in copying UAA code and using internal classes.
Do you provide any integration of UAA into the Camunda Client, or do you have any suggestions on how to get the UAA authentication header into the http request?
hi @eduard-polar-knoll in our UAA documentation there is example that you don’t need to use Spring in order to use uaa-rest-client.
https://geta12.com/docs/?release=2022.06#content:asciidoc,product:UAA,artifact:uaa-documentation-src,scene:UAA,anchor:rest-client-usage-java
You would need to build the factory on your own. Please aware the factory should be reused as long as you need communication for different URL which can be used for same token.
Yes, but how do I wire that with the org.camunda.bpm.client.ExternalTaskClient of Camunda?
actually what you need is the token which generated from IDP. If you know how to take the token then you can pass to the header “Authorization” for every requests you send to Camunda. Then if Camunda use token verification which also fetch certificate from the sam IDP then it should be authenticated.
Well, the code how to acquire that token is already implemented in the UAA classes (depending on the authentication type). So I am still faced with the option, that I either copy the code from UAA into my own code or use those internal UAA classes.
the code how to acquire the token is done via API of UAA like the documentation i sent to you.
The thing you have to do here is take the token which store in your configuration look at your configuration if you have UAARestClientProperties.authorizationDataStore
Put it in to the request which created within Camunda.
Send to server which use UAA as token verification.
Look at the property:
mgmtp.a12.uaa.authentication.client.rest.authorizationDataStore=file:/a/auth.txt or mgmtp.a12.uaa.authentication.client.rest.authorization-data-store=file:/a/auth.txt
Well, actually, the code I need is in com.mgmtp.a12.uaa.client.rest.auth.token.internal.UAACertificateTokenAcquirer (btw: mgmtp.a12.uaa.authentication.client.rest.authorization-data-store is marked as “Does not work with CERTIFICATE”).
Or in the other implementations of com.mgmtp.a12.uaa.client.rest.auth.TokenAcquirer, if we decide to switch the authentication type at some point.
What I cannot see is how I can get a hand on the correct TokenAcquirer without having to create the instance by myself.
Of course I can read the properties and read the token (depending on what it is) from the configured location by myself, but that feels kind of wrong when the code that does that already exists.
it depends how you want it be.
You want to use UAA to acquire token, you configure the property so it knows how to take the token by using Acquirers.
UAA askes you where to store it then you specify the location.
Then I think it’s fine for you to take it in any other places and past it around.