Initial Client for Configuring Janssen

[tawaren]

I currently in the process on migrating from the docker monolith to a helm deployment.
I have a docker container that when started waited until the config-api was ready and then deployed interception scripts and other configurations. It used the test client that was set up over environment variables in the docker-compose yaml file.
This was ok as it was just for testing, of course it was not the securest way to do it.

Now I'm struggeling on how to do this in a helm deploy.

How do I generate the first client (automated over a script or helm configuration), which I then can use to deploy my configurations?
I saw something for the TUI (https://docs.jans.io/v1.1.6/janssen-server/kubernetes-ops/tui-k8s/). However id would like to do this automated over the REST API. I assume their is an elegant way to do this, which i just did not find.

[tawaren]

When I use the tui_client to access the config-api over REST I run into a Insufficient scopes! problem.

I get following error (reading current config):
oAuth authorization error Insufficient scopes! , Required scope: [https://jans.io/oauth/jans-auth-server/config/properties.readonly], however token scopes: [jans_stat, openid, https://jans.io/oauth/jans-auth-server/config/adminui/properties.readonly, https://jans.io/oauth/jans-auth-server/config/adminui/license.write, https://jans.io/oauth/config/stats.readonly, https://jans.io/oauth/jans-auth-server/config/adminui/license.readonly]

When fetching the token I request the following scopes:
"https://jans.io/oauth/jans-auth-server/config/properties.readonly"
"https://jans.io/oauth/config/scripts.write"
"https://jans.io/oauth/jans-auth-server/config/properties.write"
"https://jans.io/oauth/config/scripts.write"
"https://jans.io/oauth/config/scopes.write"

I added the first one just to make sure, the properties.write did suffice in the monolith.
So it seems the tui client does not have enough scopes to use the config-api over Rest.

[tawaren]

I figured out that their is a test_client as well. With that client it works.
Is using the test_client the prefered approach for a production system to do automatic configuration?
The name test is a bit confusing.

[nynymike]

@misba7 any thoughts? If Markus was confused, probably others will also find it confusing.

[misba7]

Hi Markus.
Yeah. test client-id and secret have sufficient scopes, and thus they will work with you.
You can see them used here in Terraform too.

We'll discuss internally the client naming.

[moabu]

Hi @tawaren ,

The test client has almost all the scopes and its created during setup if selected with the docker monolith(jans linux setup creates it). We use that client to run the terraform test suite which is why its prefixed TEST_CLIENT. The TUI client should have enough permissions to run the TUI given the services you initially selected.This is also true given a cloud native setup (helm) . If there is a problem with that client then an issue should be open regarding missing scopes in that client. The test client again is used for the testing suite and can be turned off and on . We prefer if running Terraform that a client is created with the right scopes that access the APIs that will be used . In any case the test client can also be used with Terraform as it has all the scopes Terraform could possibly call.