Is it possible to test the policy-referring-connector-extension with my own connector-setup?

[Julian-Marco]

So far, I integrated the policy-referring-connector-module into my own EDC-repository (currently working on milestone-6 with a couple of other extensions). I'd like to test the extension locally by starting up two localhost-connectors on the ports 8181, 8182, 8282 and 9191, 9192, 9292 respectively. Both connectors contain the policy-referring-connector-module. My provider-connector receives the policy by curling its policydefinitions-endpoint:

curl -X POST -H "Content-Type: application/json" -H "X-Api-Key: password" -d @policy/contractpolicy.json "http://localhost:8182/api/v1/data/policydefinitions"

The contractpolicy.json looks like this:

    "id": "use-restricted",
    "policy": {
        "permissions": [
            {
                "edctype": "dataspaceconnector:permission",
                "uid": null,
                "target": null,
                "action": {
                    "type": "USE",
                    "includedIn": null,
                    "constraint": null
                },
                "assignee": null,
                "assigner": null,
                "constraints": [
                    {
                        "edctype": "AtomicConstraint",
                        "leftExpression": {
                            "edctype": "dataspaceconnector:literalexpression",
                            "value": "REFERRING_CONNECTOR"
                        },
                        "rightExpression": {
                            "edctype": "dataspaceconnector:literalexpression",
                            "value": "http://localhost:9292"
                        },
                        "operator": "EQ"
                    }
                ],
                "duties": []
            }
        ],
        "prohibitions": [],
        "obligations": [],
        "extensibleProperties": {},
        "inheritsFrom": null,
        "assigner": null,
        "assignee": null,
        "target": null,
        "@type": {
            "@policytype": "set"
        }
    }
}

The contractoffer.json matches the policy accordingly (as it is needed anyway). I start the negotiation by using the following command:

curl -X POST -H "Content-Type: application/json" -H "X-Api-Key: password" -d @policy/policy-01-contract-negotiation/contractoffer.json "http://localhost:9192/api/v1/data/contractnegotiations"

Unfortunately, no matter what value I insert here,

                        "rightExpression": {
                            "edctype": "dataspaceconnector:literalexpression",
                            "value": "http://localhost:9292"
                        },

my consumer always receives the following error message:

DEBUG 2023-05-10T10:31:05.5155777 ContractRejectionHandler: Received contract rejection to message null. Negotiation process: 127dbd1e-ac64-4eb3-b9c1-894f0f142f40. Rejection Reason: "Policy use-restricted not fulfilled"^^http://www.w3.org/2001/XMLSchema#string

I was told that I'd need the basic connector url, so I tried it with http://localhost:9191, http://localhost:9192 and http://localhost:9292, but the outcome is always the same. The relevant part of the config.properties of the consumer looks like this:

web.http.port=9191
web.http.path=/api
web.http.data.port=9192
web.http.data.path=/api/v1/data
web.http.ids.port=9292
web.http.ids.path=/api/v1/ids
edc.api.auth.key=password
edc.hostname=localhost
ids.webhook.address=http://localhost:9292
edc.ids.id=urn:connector:consumer

From my understanding, the whole setup should work with localhost-connectors, but maybe I'm wrong here. Even then, would deploying and exposing the connectors help anyway? Or does it only work when using the whole sovity-setup in general?

[richardtreier]

The "referring connector" policy does not validate any asset properties, as they are insecure and freely settable on the provider side.

The "referring connector" policy validates a claim value in the DAT returned by the DAPS for the requesting connector.

This requires you to have a DAPS, meaning, you need to have a fully secured and running data space.

That means, there is currently no good way to integration test the extension in a local development environment with two connectors, unless you can set up a DAPS locally, set up DNS locally, that the DAPS needs, etc.

[Julian-Marco]

Thank you! I don't know anything about DAPS to be honest, but I read that it has something to do with the Oauth2-Protocol. At the moment, our connectors use the oauth2-core-extension of the EDC: https://github.com/eclipse-edc/Connector/tree/main/extensions/common/iam/oauth2/oauth2-core

We have a single Keycloak instance running in the Cloud that has all of our connectors registered in the sense that all of the connectors hold a keystore file that is also loaded into their respective clients in Keycloak. By that, only those connectors that are part of the Keycloak network are capable of communicating with each other. Is this in any kind of way translatable to the situation here? Or would we have to use another extension, for example this one?

https://github.com/eclipse-edc/Connector/tree/main/extensions/common/iam/oauth2/oauth2-daps

[SebastianOpriel]

A DAPS is a central component of a Dataspace and is required for most of the current DataSpaces (at least Catena-X, Mobility Dataspace). So you will not be able to use a Connector unless you are connected to a DAPS. A reference implementation can be found here: https://github.com/Fraunhofer-AISEC/omejdn-server
You may re-use following testbed, where a DAPS is configured (but other connectors are used, which are not compatible with the EDC). https://github.com/International-Data-Spaces-Association/IDS-testbed

[SebastianOpriel]

About your Keycloak Instance: You might miss some claims in the Keycloak, which might be necessary for Dataspace Interactions