Why happen this warning. [WARN] Request guard `ApiKey < IdsClaims, Empty >` is forwarding

[sey323]

Hi, I`m trying to create Clearing House App on docker and to connect fiware-true-connector.

First, I create only Clearing House App(exclued Clearing House Processor) and i requested sample request by Postman.(Daps use default one.) But The following message was returned.

Token not valid!

At that time, bellow log is following on Crearing House App.

logging-service          | [2022-06-20][02:11:23][hyper::client::pool][DEBUG] pooling idle connection for "https://daps.aisec.fraunhofer.de/"
logging-service          | [2022-06-20][02:11:23][reqwest::async_impl::response][DEBUG] Response: '200 OK' for https://daps.aisec.fraunhofer.de/.well-known/jwks.json
logging-service          | [2022-06-20][02:11:23][tokio_reactor::registration][DEBUG] scheduling Read for: 0
logging-service          | [2022-06-20][02:11:23][tokio_reactor::registration][DEBUG] scheduling Read for: 0
logging-service          | [2022-06-20][02:11:23][core_lib::api::auth][DEBUG] ...got jwks from daps
logging-service          | [2022-06-20][02:11:23][_][WARN] Request guard `ApiKey < IdsClaims, Empty >` is forwarding. # this point
logging-service          | [2022-06-20][02:11:23][_][INFO] Outcome: Forward
logging-service          | [2022-06-20][02:11:23][_][INFO] Matched: (unauth) POST /messages/log/<_pid> [50] application/json
logging-service          | [2022-06-20][02:11:23][_][INFO] Outcome: Success
logging-service          | [2022-06-20][02:11:23][_][INFO] Response succeeded.

I thought jwt token is return complete, but its key may not set on ApiKey(this point above).

sample curl requests is here i requesed. from this docs.

curl --location --request POST 'http://localhost:8000/messages/log/default' \
--header 'Content-Type: application/json' \
--data-raw '{
  "@context" : {
    "ids" : "https://w3id.org/idsa/core/",
    "idsc" : "https://w3id.org/idsa/code/"
  },
  "@type" : "ids:LogMessage",
  "@id" : "https://w3id.org/idsa/autogen/logMessage/c6c15a90-7799-4aa1-ac21-9323b87a7xv9",
  "ids:securityToken" : {
    "@type" : "ids:DynamicAttributeToken",
    "@id" : "https://w3id.org/idsa/autogen/dynamicAttributeToken/6378asd9-480d-80df-c5cb02e4e260",
    "ids:tokenFormat" : {
      "@id" : "idsc:JWT"
    },
    "ids:tokenValue" : ""# toke from /.well-known/jwks.json token.
  },
  "ids:senderAgent" : "http://example.org",
  "ids:modelVersion" : "4.0.0",
  "ids:issued" : {
    "@value" : "2020-12-14T08:57:57.057+01:00",
    "@type" : "http://www.w3.org/2001/XMLSchema#dateTimeStamp"
  },
  "ids:issuerConnector" : {
    "@id" : "https://companyA.com/connector/59a68243-dd96-4c8d-88a9-0f0e03e13b1b"
  }
}'

Not this case, I also got the same warn when connect by the Fiware True Connector. Why

Why happen this warning? Please help me with this issue... Thanks.

[kragall]

The simple answer is that you are sending your requests to the wrong API. Even worse, you are using outdated sample requests.

The sample requests you found were for version v0.5 of the CH and will not longer work. I wasn't aware that those were still in the repository, so I deleted them. Please check the IDS-G-Pre for a more up-to-date version.

Regarding the APIs, have a look at this picture:

It is important to understand that the Clearing House API (IDS) (multipart/IDSCP2) is the endpoint for communication with the connectors. And it is provided by the Clearing House Processors in conjunction with the Trusted Connector. So, if you did not build the processors nor run the Trusted Connector, the API of the CH will not be available.

The Clearing House App you build provides the APIs Logging Service API, Document API and Keyring API, which are all internal APIs.

[sey323]

Thanks！

First, IDS-G-Pre could not be confirmed.. its appear 404. I would like you to confirm that the URL is correct.

Second. This mean..

And it is provided by the Clearing House Processors in conjunction with the Trusted Connector. So, if you did not build the processors nor run the Trusted Connector, the API of the CH will not be available.

Does it mean that Fiware True Connector cannot connect to this CH? I lookat this page and put the following setting in Fiware True Connector.

CLEARING_HOUSE=http://{my-clearing-house-ip}/message/log/test-message

Maybe this CH to Fiware True Connector connection is not supported？ Is it possible to connect only to the Trusted Connector?

[kragall]

The IDS-G-Pre is an internal repository of the IDSA. All members of the IDSA may get access, but you have to contact them if you do not have access already (and 404 indicates that you don't).

Does it mean that Fiware True Connector cannot connect to this CH? I lookat this page and put the following setting in Fiware True Connector.

No, all connectors may communicate with the CH. But, the CH as a component runs on the Trusted Connector.

[sey323]

I see. I`m not member so I can't browse. Please update the README instead of delete it. Is it possible?

the CH as a component runs on the Trusted Connector.

Does HC need to run together Trusted Connector? docker-compose that i created is here. Now, i only build CH.

version: '3.0'

services:
    logging-service:
        container_name: "logging-service"
        build: 
            context: .
            dockerfile: ./docker/logging-service-multistage.Dockerfile
        depends_on:
            - document-api
            - keyring-api
            - logging-service-mongo
        environment:
            # Allowed levels: Off, Error, Warn, Info, Debug, Trace
            - API_LOG_LEVEL=Debug
        ports:
            - "8000:8000"
        volumes:
            - ./clearing-house-app/logging-service/Rocket.toml:/server/Rocket.toml
            - ./clearing-house-app/logging-service/keys:/server/keys
            - ./clearing-house-app/logging-service/certs:/server/certs

    document-api:
        container_name: "document-api"
        build: 
            context: .
            dockerfile: ./docker/document-api-multistage.Dockerfile
        depends_on:
            - keyring-api
            - document-mongo
        environment:
            # Allowed levels: Off, Error, Warn, Info, Debug, Trace
            - API_LOG_LEVEL=Info
        ports:
            - "8001:8001"
        volumes:
            - ./clearing-house-app/document-api/Rocket.toml:/server/Rocket.toml
            - ./clearing-house-app/certs:/server/certs

    keyring-api:
        container_name: "keyring-api"
        build: 
            context: .
            dockerfile: ./docker/keyring-api-multistage.Dockerfile
        depends_on:
            - keyring-mongo
        environment:
            # Allowed levels: Off, Error, Warn, Info, Debug, Trace
            - API_LOG_LEVEL=Info
        ports:
            - "8002:8002"
        volumes:
            - ./clearing-house-app/keyring-api/init_db:/server/init_db
            - ./clearing-house-app/keyring-api/Rocket.toml:/server/Rocket.toml
            - ./clearing-house-app/certs:/server/certs

    logging-service-mongo:
        container_name: "logging-service-mongodb"
        image: mongo:latest
        environment: 
            MONGO_INITDB_DATABASE: process
        volumes:
            - ./data/mongo/logging-service:/data/db

    document-mongo:
        container_name: "document-mongo"
        image: mongo:latest
        environment: 
            MONGO_INITDB_DATABASE: document
        volumes:
            - ./data/mongo/document-service:/data/db

    keyring-mongo:
        container_name: "keyring-mongo"
        image: mongo:latest
        environment: 
            MONGO_INITDB_DATABASE: keyring
        volumes:
            - ./data/mongo/keyring-service:/data/db

Is it the reason why you can't connect to Fiware True Connector because you didn't build Trusted Connector together?

[kragall]

Does HC need to run together Trusted Connector

Yes, this implementation uses the Trusted Connector as a basis, which means a TC must be run together with the other docker containers.

Is it the reason why you can't connect to Fiware True Connector because you didn't build Trusted Connector together?

I don't really understand the question. What do you mean with "connect"? Communication of Connectors is done via protocols like IDS multipart or IDSCP2. This implementation of the Clearing House Service is based on the Trusted Connector not the True Container. As of now, there are no standardized interfaces inside the connectors (DSC, EDC, True Connector, Trusted Connector, etc.) to integrate apps. So, the connector used to integrate the app is not interchangeable without modifying the app.

[sey323]

Oh.. Sorry. I misunderstood that this CH can be used in common with all IDS Connectors, including Trusted and True connectors.I found that CH needs to be built for each IDS Connector. I try using Trusted Connecctor. Thanks!

Finally, could you give me a sample request to check the API operation without Trusted Connector? Or Could you list it in READEME?

[kragall]

Sorry, but I don't have sample requests for the internal api. It recently changed and is scheduled to change again soon.

The best advice I can give you is to start from the other direction and first setup TC with the Clearing House processors. There are integration tests you can run (ignore the idscp2 tests for the beginning, only use the multipart tests) and you won't have to worry about how the requests need to look like.

If you run netcat -p -l 8000 instead of the logging-service, and run one of the tests, you can see the requests the TC tries to forward to the internal api.

[sey323]

Sorry for the late reply.

I will try to see if I can connect using TC.Thanks for the answer.