Implement publish button hook

[blcham]

A/C:

• publish button triggers post method provided in application.yml (docker-compose.yml) with sample json.
• configuration to docker-compose is provided here so it calls backend import method

[blcham]

Current solution:

• it works when calling the same docker instance
• records are not yet moved completed --> published

[blcham]

Script to forward ports:

#!/bin/bash

REMOTE_GRAPHDB_PORT=5006
LOCAL_GRAPHDB_PORT=5006

# check port availability
#lsof -ti:$LOCAL_GRAPHDB_PORT >/dev/null && echo -e "ERROR: Local port $LOCAL_GRAPHDB_PORT is already in use. Check with command:\nps -AF | grep \`lsof -ti:$LOCAL_GRAPHDB_PORT\`"  && exit

ssh -f -N -L ${LOCAL_GRAPHDB_PORT}:localhost:${REMOTE_GRAPHDB_PORT} kbss.felk.cvut.cz
chromium http://localhost:${LOCAL_GRAPHDB_PORT}

[blcham]

@kostobog most-likely authorization header contains:

• client id
• context (operation to do)
• authorization token

I would compare authorization headers of the following requests:

• manual import of operator guy -- operator guy logins to AVA using operator's keycloak instance and uses "import records" button in AVA instance
• automatic publish method of operator guy -- operator guy logins to AVA using operator's keycloak instance and hits publish button in Operator's instance

Maybe we need to test it first with @PreAuthorize("permitAll()")

[blcham]

@kostobog have a look at:
https://chatgpt.com/share/78d280e0-fbf3-418c-a194-587c6d095186

And also have a look at https://www.keycloak.org/docs/latest/securing_apps/#_token-exchange.

[kostobog]

@blcham
In kbss-cvut/record-manager#65 it is possible to publish the records to supplier using the publish button in operator.

• tested with or without permitall. In current version peremitall is removed

The solution requires additional configuration, see kbss-cvut/23ava-distribution#143.

• PUBLISH_RECORDS_SERVICE_SECRET - specifies the client secret for the server in the supplier.
  • The client_id corresponding to the secret is hardcoded. May be it should be passed as configuration parameter as well?
• EXCHANGE_TOKEN_SERVICE_URL - this is the oidc service at the supplier which supports token exchange

Currently the variables are set operator's .env

Required Supplier keycloak configuration

The following steps were inspired by 7.3. Internal token to external token exchange. The main difference is that the permissions are added to the identity provider no to the client as is described in the documentation.

1. Go to record-manager realm, tab Permissions
2. Make sure Permissions enabled is on.
3. Click the token-exchange link the Permission list section
4. Set Decision strategy to Affirmative and save
5. Click Client details link in the breadcrumb at the top and select Policies tab
6. Click button to create a policy, from the Policy type choose the Client policy type. Set the name and select the client (record-manager-server) for which the policy applies and save.
7. Go to the token-exchange permission page, see steps 1-3, select the policy created in step 6. and save.

[blcham]

@kostobog let's discuss:

The client_id corresponding to the secret is hardcoded. May be it should be passed as configuration parameter as well?

[blcham]

Documentation about configuration is described in https://github.com/kbss-cvut/23ava-distribution/pull/151