search

International-Data-Spaces-Association / omejdn-daps

Open Source implementation of the Dynamic Attribute Provisioning Service based on http://github.com/Fraunhofer-AISEC/omejdn-server
Apache License 2.0
5 stars 10 forks source link

Issues with IDSCP2 #20

Closed aitorcelaya closed 2 years ago

aitorcelaya commented 2 years ago

I am trying to use IDSCP2 with a Dataspace Connector v7.0.1 in a local setup with the Omejdn DAPS.

I have successfully tested DSC to Omejdn DAPS with HTTPS (local instance) I have successfully tested DSC to FH AISEC's DAPS with IDSCP2 (remote/public)

I am trying to test DSC to Omejdn DAPS with IDSCP2 (local instance). IDSCP2 in the DSC wants by default to connect with the endpoint /v2/token.

I wento into config/oauth_providers.yml and updated the following:

From

token_endpoint: 'https://token'

To

token_endpoint: 'https://v2/token'

I am still not able to obtain a DAT from the DSC.

In the Omejdn's terminal I simply get a line with 404 (Reverseproxy + DAPS):

omejdn-server | 172.18.0.2 - - [01/Mar/2022:15:36:53 +0000] "POST /v2/token HTTP/1.1" 404 476 0.0026 omejdn | 172.18.0.4 - - [01/Mar/2022:15:36:53 +0000] "POST /v2/token HTTP/1.1" 404 476 "-" "okhttp/4.9.3"

In the DSC's side it does find the Omejdn DAPS because of the Sinatra message but there is some type of issue:

2022-03-01T15:36:53,985 [https-jsse-nio-7084-exec-4] ERROR - PRODUCTIVE_DEPLOYMENT: No IDS-Message sent! No DAT could be acquired from DAPS! [code=(IMSCOE0001), reason=(Error connecting to DAPS (possibly currently not reachable or wrong DAPS-URL): Unexpected code Response{protocol=http/1.1, code=404, message=Not Found, url=https://omejdn/v2/token} Body: <!DOCTYPE html>\n\n\n \n\n\n

Sinatra doesn’t know this ditty.

\n \n
\n Try this:\n 
post '/v2/token' do\n  "Hello World"\nend\n
\n
\n\n\n)] 2022-03-01T15:36:53,986 [https-jsse-nio-7084-exec-4] WARN - Connection to DAPS could not be established. [exception=(Error connecting to DAPS (possibly currently not reachable or wrong DAPS-URL): Unexpected code Response{protocol=http/1.1, code=404, message=Not Found, url=https://omejdn/v2/token} Body: <!DOCTYPE html>\n\n\n \n\n\n

Sinatra doesn’t know this ditty.

\n \n
\n Try this:\n 
post '/v2/token' do\n  "Hello World"\nend\n
\n
\n\n\n)] 2022-03-01T15:36:54,015 [https-jsse-nio-7084-exec-4] WARN - Unable to retrieve valid DAT. [exception=(Access is denied)]

Is it something I have misconfigured regarding the /v2/token or does the Omejdn DAPS not support IDSCP2 at the moment?

gbrost commented 2 years ago

Hi there, so let me try to understand the problem: The DAPS does only support HTTP(S) calls. But you write "I have successfully tested DSC to FH AISEC's DAPS with IDSCP2 (remote/public)". So you mean: You set up the DSP to use IDSCPv2 and want to configure IDSCPv2 to request a DAT from DAPS?

The calls themselves to acquire a DAT are always https based. A simple post to /v2/token will not serve as a valid test, since you need a request token to test the endpoint. Modifying the outh_providers file does not work, since you can enable other oauth providers with that file. The token endpoint should be configurable with the DSC/IDSCPv2. @milux should know more about what revision you need.

oxisto commented 2 years ago

Hi there, so let me try to understand the problem: The DAPS does only support HTTP(S) calls. But you write "I have successfully tested DSC to FH AISEC's DAPS with IDSCP2 (remote/public)". So you mean: You set up the DSP to use IDSCPv2 and want to configure IDSCPv2 to request a DAT from DAPS?

The calls themselves to acquire a DAT are always https based. A simple post to /v2/token will not serve as a valid test, since you need a request token to test the endpoint. Modifying the outh_providers file does not work, since you can enable other oauth providers with that file. The token endpoint should be configurable with the DSC/IDSCPv2. @milux should know more about what revision you need.

For me this seems to be the problem related to „v2“ again. DAPS expects a request to /token, not /v2/token.

aitorcelaya commented 2 years ago

From your input, I have reverted the changes I did to the oauth_providers.yml as they do not apply in here. The local DAPS is working without the /v2, that is correct.

My first scenario was testing two local DSC v7.0.1 with IDSCPv2 and the public FH DAPS (https://daps.aisec.fraunhofer.de).

DSC v7.0.1 with IDSCPv2 as Provider:

2022-03-03T08:59:28,091 [main] INFO -     Started idscp2Server (idscp2server://0.0.0.0:29292)
2022-03-03T08:59:28,091 [main] INFO -     Started notification-handler-route (direct://notificationMsgHandler)
2022-03-03T08:59:28,092 [main] INFO -     Started policyCheck (direct://policyCheck)
2022-03-03T08:59:28,092 [main] INFO -     Started resourceUpdateHandler (direct://resourceUpdateHandler)
2022-03-03T08:59:28,092 [main] INFO -     Started subscription-handler-route (direct://subscriptionMsgHandler)
2022-03-03T08:59:28,093 [main] INFO -     Started route1 (direct://deadLetterChannel)
2022-03-03T08:59:28,093 [main] INFO - Apache Camel 3.15.0 (camel-1) started in 2s312ms (build:254ms init:1s464ms start:594ms)
2022-03-03T08:59:28,210 [scheduling-1] INFO - Scanning agreements...
2022-03-03T08:59:28,211 [main] INFO - Started ConnectorApplication in 75.818 seconds (JVM running for 78.128)
2022-03-03T09:00:14,316 [https-jsse-nio-7084-exec-5] INFO - Initializing Spring DispatcherServlet 'dispatcherServlet'
2022-03-03T09:00:14,316 [https-jsse-nio-7084-exec-5] INFO - Initializing Servlet 'dispatcherServlet'
2022-03-03T09:00:14,325 [https-jsse-nio-7084-exec-5] INFO - Completed initialization in 8 ms
2022-03-03T09:00:16,348 [https-jsse-nio-7084-exec-5] INFO - Successfully received DAT from DAPS.
2022-03-03T09:00:16,666 [https-jsse-nio-7084-exec-5] INFO - Cached DAPS DAT expired or no expiration set. [expiration=(null)]
2022-03-03T09:00:16,916 [https-jsse-nio-7084-exec-5] INFO - Successfully received DAT from DAPS.
2022-03-03T09:00:18,228 [Thread-2] INFO - Retrieving Dynamic Attribute Token from DAPS ...
2022-03-03T09:00:23,754 [https-jsse-nio-7084-exec-5] INFO - Sending data via connection 800bab3f-fc5b-4ca1-9329-c354272f835a...
2022-03-03T09:00:28,270 [scheduling-1] INFO - Scanning agreements...

DSC v7.0.1 with IDSCPv2 as Consumer:

2022-03-03T08:59:32,822 [main] INFO -     Started idscp2Server (idscp2server://0.0.0.0:29292)
2022-03-03T08:59:32,822 [main] INFO -     Started notification-handler-route (direct://notificationMsgHandler)
2022-03-03T08:59:32,822 [main] INFO -     Started policyCheck (direct://policyCheck)
2022-03-03T08:59:32,822 [main] INFO -     Started resourceUpdateHandler (direct://resourceUpdateHandler)
2022-03-03T08:59:32,822 [main] INFO -     Started subscription-handler-route (direct://subscriptionMsgHandler)
2022-03-03T08:59:32,822 [main] INFO -     Started route1 (direct://deadLetterChannel)
2022-03-03T08:59:32,822 [main] INFO - Apache Camel 3.15.0 (camel-1) started in 1s622ms (build:418ms init:849ms start:355ms)
2022-03-03T08:59:32,869 [main] INFO - Started ConnectorApplication in 73.027 seconds (JVM running for 77.685)
2022-03-03T08:59:32,872 [scheduling-1] INFO - Scanning agreements...
2022-03-03T09:00:18,448 [Thread-2] INFO - Retrieving Dynamic Attribute Token from DAPS ...
2022-03-03T09:00:24,193 [Thread-12] INFO - 
2022-03-03T09:00:24,237 [Thread-12] INFO - Requesting public key of token issuer. [url=(https://daps.aisec.fraunhofer.de/.well-known/jwks.json), kid=(TCUFeCNazalKHg9KzrzLIAzRWTMDDWSa7LcM9ZwHMyo)]
2022-03-03T09:00:24,842 [Thread-12] INFO - Successfully received DAT from DAPS.
2022-03-03T09:00:25,402 [Thread-12] INFO - Sending data via connection 154eb9aa-f605-4cd7-82d2-5eb4ad5abebf...
2022-03-03T09:00:32,893 [scheduling-1] INFO - Scanning agreements...

I then tried replicating the same scenario with our local Omejdn DAPS (https://omejdn).

I will attach the Omejdn DAPS side logs in here:

omejdn-server  | "No claim mappers available"
omejdn-server  | == Sinatra (v2.1.0) has taken the stage on 4567 for development with backup from Thin
omejdn-server  | 172.18.0.2 - - [03/Mar/2022:10:47:40 +0000] "POST /token HTTP/1.1" 200 1289 0.0935
omejdn         | 172.18.0.4 - - [03/Mar/2022:10:47:40 +0000] "POST /token HTTP/1.1" 200 1289 "-" "okhttp/4.9.3"
omejdn         | 172.18.0.4 - - [03/Mar/2022:10:47:43 +0000] "POST /v2/token HTTP/1.1" 404 476 "-" "okhttp/4.9.3"
omejdn-server  | 172.18.0.2 - - [03/Mar/2022:10:47:43 +0000] "POST /v2/token HTTP/1.1" 404 476 0.0024
omejdn         | 172.18.0.5 - - [03/Mar/2022:10:47:47 +0000] "POST /v2/token HTTP/1.1" 404 476 "-" "okhttp/4.9.3"
omejdn-server  | 172.18.0.2 - - [03/Mar/2022:10:47:47 +0000] "POST /v2/token HTTP/1.1" 404 476 0.0036
omejdn         | 172.18.0.4 - - [03/Mar/2022:10:47:53 +0000] "POST /v2/token HTTP/1.1" 404 476 "-" "okhttp/4.9.3"
omejdn-server  | 172.18.0.2 - - [03/Mar/2022:10:47:53 +0000] "POST /v2/token HTTP/1.1" 404 476 0.0138
omejdn         | 172.18.0.5 - - [03/Mar/2022:10:47:53 +0000] "POST /v2/token HTTP/1.1" 404 476 "-" "okhttp/4.9.3"
omejdn-server  | 172.18.0.2 - - [03/Mar/2022:10:47:53 +0000] "POST /v2/token HTTP/1.1" 404 476 0.0046
omejdn-server  | 172.18.0.2 - - [03/Mar/2022:10:47:58 +0000] "POST /v2/token HTTP/1.1" 404 476 0.0048
omejdn         | 172.18.0.4 - - [03/Mar/2022:10:47:58 +0000] "POST /v2/token HTTP/1.1" 404 476 "-" "okhttp/4.9.3"
omejdn-server  | 172.18.0.2 - - [03/Mar/2022:10:47:59 +0000] "POST /v2/token HTTP/1.1" 404 476 0.0015
omejdn         | 172.18.0.5 - - [03/Mar/2022:10:47:59 +0000] "POST /v2/token HTTP/1.1" 404 476 "-" "okhttp/4.9.3"

I can now see that the IDSCPv2 part of the DSC is forcing the /v2 when I have clearly stated that the DSC should point to the Omejdn DAPS without it:

## DAPS
daps.url=https://omejdn
daps.token.url=https://omejdn/token

I will open a parallel issue in the Dataspace Connector so see how I can change the DAPS url when IDSCPv2 is set to true.

Related issue open International-Data-Spaces-Association/DataspaceConnector#42

milux commented 2 years ago

Please have a look at the linked issue for my answers on this.

bellebaum commented 2 years ago

May I assume that the issue has been fixed and close this issue?

tmberthold commented 2 years ago

Following the issue, the following PR should fix it (not yet merged): https://github.com/International-Data-Spaces-Association/DataspaceConnector/pull/141/files

bellebaum commented 2 years ago

Then I think the DAPS-Repo no longer neeeds it. Closing...