international-data-spaces-association / ids-messaging-services Goto Github PK

Check within Framework if Infomodel Versions of outgoing and incoming messages are identical

The DAT JWT contains a kid field, in which the kid of the PublicKey which can be used for validation is given.
This information should be used instead of relying on kids given in the application.properties file.

We are using Lombok as a dependency in the framework-pom (parent pom). With Lombok it is not necessary to have

private static final Logger LOGGER = LoggerFactory.getLogger(OrbiterTokenManagerService.class);

in each class, just use at class definition

@Slf4j (in our case)

instead.

Logging annotation (in our case):
https://projectlombok.org/api/lombok/extern/slf4j/Slf4j.html

Overview Lombok annotations
https://projectlombok.org/features/all

Various functionalities must be adapted so that IDS-LDP/REST can be integrated in addition to Multipart.

The existing DAT validation functionalities are to be extended to include more advanced DAT attribute validation.

https://github.com/International-Data-Spaces-Association/framework-library/blob/development/core/src/main/java/de/fraunhofer/ids/framework/daps/DapsVerifier.java

The Apache Maven Checkstyle plugin can be used to list any further code quality adjustments needed.

I will use this plugin for the current state of the Unified-Lib and make any necessary reasonable adjustments.

http://maven.apache.org/plugins/maven-checkstyle-plugin/index.html

Test classes need to be adapted.

Issue being worked on in the IDS-Framework project, changes to the IDS-Framework also need to be made here.

Problem:
Loading the Keystore if it is not directly in the resources-folder but in a subfolder. (Probably must use Spring-ClassPathResource instead of the current solution)

The connector developer should be able to choose which protocol to use when sending a message using the framework.
In addition, there should be a default value if the connector developer does not specify a send protocol.
(REST / Multipart)

There seems to be a new Info-Model version 4.0.2, check if this should be used.

In addition to the DAPS implemented, the Orbiter-DAPS is also to be included into the architecture. The Demo-Connector already contains functionalities for connecting to the Orbiter-DAPS.

It is possible to send IDS-messages even though they did not get a valid DAPS DAT. In the future this will no longer be possible unless the connector is in test_deployment state. Instead, an exception is returned to the connector developer depending on the reason for the failure of the DAT acquisition.

Already implemented in the IDS-Framework for a new major version 5.0.0, which is yet to be officially released.

International-Data-Spaces-Association/IDS-Connector-Framework#9

Wherever the enum MultiDatapart is used in the framework-library, the toString() function should be used instead of name(). function.

The functionalities adopted from the IDS-Framework to communicate with an IDS-Broker should be adapted along the rest of the unified-lib architecture (only minor adjustments necessary).

The connector should be enabled to block specific connectors or tokens itself. For this purpose, a functionality should be created to check incoming messages whether their token / connector is on a blacklist.

Hi all,

I am contacting you on behalf of @ssteinbuss, CTO of IDSA.

As Technology and Architecture team of IDSA, we would like to organize a monthly call (60 mins) with the maintainers of IDSA repositories to discuss about the work and rules (license, code of conduct, issue labels, how to contribute file) for each repo.

As maintainers of this repo, can you please provide us your email address? So that we can create a contact list and organize our kick-off meeting?
(you can either reply here or send a direct e-mail to me at: [email protected])

Thank you,
Best regards,

• Naming: IDS-Messaging-Services
• Discussion Area
• Contribution Guideline
• Code Of Conduct
• Labels like other IDSA projects
• Dependabot
• Protect Master

The default communication path is that a Response-Message is expected in response to a sent Request-Message. This is synchronous message flow.

Nevertheless, the message types of the IDS also allow asynchronous message flow. It is possible that a RequestInProcessMessage (type of NotificationMessage) is first received in response to a sent Request-Message, and after that then the actual Response-Message. Such a message flow is asynchronous.

It must be checked to what extent the current state of the Unified Lib supports asynchronous message flow, since with an asynchronous message flow the actual Response-Message would arrive at the Endpoint of the Unified-Lib as a normal message without direct connection within a message history.

http://htmlpreview.github.io/?https://github.com/IndustrialDataSpace/InformationModel/blob/feature/message_taxonomy_description/model/communication/Message_Description.htm

We need to see if we have the ability to send SPARQL-queries to the broker so that the user just has to give us a keyword, so we assemble the query and send the broker a query message.

PREFIX ids: <https://w3id.org/idsa/core/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT DISTINCT ?resultUri ?res { 
  GRAPH ?g { 
    { ?resultUri a ids:Resource } 
    UNION 
    { ?resultUri a ids:BaseConnector }
    ?resultUri ?predicate ?res .
    FILTER ( DATATYPE(?res) = xsd:string ) .
    FILTER(REGEX(?res, "LOREM IPSUM", "i"))
  }
} LIMIT 5 OFFSET 0

Currently a received RejectionMessage is not forwarded to the connector-developer upon receiving it at the endpoints of the Unified-Lib due to failed DAT-validation of the received RejectionMessage within the Unified-Lib.

Background: When sending a RejectionMessage, the own DAT is NOT specified in the send RejectionMessage for security reasons. Therefore the receiving framework usually rejects the message because of a missing DAT without forwarding the message itself to the connector developer.

The received RejectionMessage should be forwarded to the connector developer so that the developer can evaluate it and the information contained like the correlationMessage, regardless of the status of the DAT-validation of the received message.

The problem is already addressed in the original IDS-Framework and, depending on the solution, will be adopted here.

IDS-Framework Issue: International-Data-Spaces-Association/IDS-Connector-Framework#11

A new stable version of the Infomodel Java classes is expected to be released on 26.04., we should switch to it as soon as the stable version is released.

Test classes need to be adapted.

The initially implemented functionalities for the clearing house should be outsourced to a separate module if possible (infrastructure component).

https://github.com/International-Data-Spaces-Association/framework-library/tree/development/messaging/src/main/java/de/fraunhofer/ids/framework/messaging/clearinghouse

The BrokerService and TokenManagers currently get their own HttpClients from the ClientProvider sending them independently from the HttpService, so their Timeout Settings are always the OkHttp default values. They should use the HttpService, so the Timeouts set there apply to the Broker and DAPS messages, too.

Another way to solve this would be to add a Method to the ClientProvider to override the default Timeouts for all generated Clients (instead of just a method to get an alternative client with other timeout settings once).

If messages with no header are received send rejection message

Already solved in original IDS-Framework project, needs to be adapted here:

International-Data-Spaces-Association/IDS-Connector-Framework#7

Currently the Broker classes return Response objects. The interaction library uses MessageAndPayload(MAP) Objects to return more defined return values. This feature should be copied in the IDS Messaging Service

Since at the moment not much is happening with the used dependencies, here is the list of licenses.

Our goal should be: Apache License, Version 2.0

Currently, we have the following dependencies with corresponding top-level licenses:

Syntax: groupId:artifactId:version License

parent:framework

• org.springframework.boot:spring-boot-starter:2.4.2 Apache License, Version 2.0
• com.squareup.okhttp3:okhttp:4.9.1 Apache License, Version 2.0
• commons-fileupload:commons-fileupload:1.4 Apache License, Version 2.0
• org.projectlombok:lombok:1.18.18 The MIT License
• javax.servlet:javax.servlet-api:4.0.1 CDDL + GPLv2 with classpath exception
• de.fraunhofer.iais.eis.ids.infomodel:java:4.0.0 Apache Version 2.0 (?)
• de.fraunhofer.iais.eis.ids:infomodel-serializer:4.0.2-SNAPSHOT Apache Version 2.0 (?)

module:core (inherits from framework)

• io.jsonwebtoken:jjwt:0.9.1 Apache License, Version 2.0
• org.bouncycastle:bcmail-jdk15on:1.68 Bouncy Castle Licence (http://www.bouncycastle.org/licence.html)
• org.bouncycastle:bcprov-jdk15on:1.68 Bouncy Castle Licence (http://www.bouncycastle.org/licence.html)
• org.json:json:20201115 The JSON License (https://mvnrepository.com/artifact/org.json/json)
• commons-codec:commons-codec:1.15 Apache License, Version 2.0
• org.bitbucket.b_c:jose4j:0.7.6 Apache License, Version 2.0

module:messaging (inherits from core)

• org.springframework:spring-web:5.3.3 Apache License, Version 2.0
• org.springframework:spring-webmvc:5.3.3 Apache License, Version 2.0
• org.springframework:spring-tx:5.3.3 Apache License, Version 2.0
• org.apache.maven.plugins:maven-project-info-reports-plugin:3.1.1 Apache License, Version 2.0

module:broker (inherits from messaging)

• no additional dependencies

module:clearinghouse (inherits from messaging)

• no additional dependencies

Last Updated: February 25, 2021

Currently, for security reasons, the DAT is not sent with the automatic sending of RejectionMessages triggered by the Unified-Lib (see tokenValue in ErrorResponse withDefaultHeader).

The DAT cannot be sent until the validation routines for the DAT of an incoming message have been expanded (Issue #15).

As a result, the DAT can be checked again for incoming RejectionMessages, otherwise they are forwarded to the connector-devloper regardless of the DAT status.

Both classes could use a code-clean-up.
For example, in the AISEC-manager there is an older method with 100+ lines of code, in the Orbiter-manager TODOs are directly in the class instead of here as issues.

Check if the Demo-Connector can be built into the Unified-Library as a separate module in its setup with the connection to the Unified-Library instead of maintaining two artifacts.

If the integration of the Demo-Connector connected with the Unified-Lib into a Test-Module is possible, the Demo-Connector should be implemented as a new Unified-Lib module.

It looks like the AISEC Clearing-House does not support multi-part messages and therefore cannot be connected with the Unified-Lib at the moment.

Further development of the functionalities of the connection of the Unified-Lib to the Clearing-House must wait for our development regarding support of further protocols.

Questions to be answered:
What protocols are supported by the Clearing-House?

[Update 12.02.21]
Clearing-House uses the Trusted-Connector. Currently, when sending messages to the clearing house, an internal server error message is returned. This may be due to the infomodel-version used.

First, the Broker-Connection functionalities of the original IDS-Framework are migrated to the Unified-Lib in order to subsequently make adjustments along to the functionalities of the Interaction-Library.

The status of release version 1.5 should be merged from Dev-Branch into Main, so that Main corresponds to the status of the latest release. Ideal would be to release new versions from the Main when the Dev/Release-branch is merged into Main and tag the merge commit as new release-version. (git-flow)

TODO taken from the OrbiterTokenManagerService class.
//TODO persist certificate, keypair and id (or decide if we even need them inside the library)

The Orbiter DAPS gives us the certificate for the connector automated instead of having it next to the library as a file. Should we persist it or not?

The current message handlers are expecting MessagePayload objects instead of Infomodel Messages. In order to keep the already existinfg message handlers i. e. in the Data Space Connector the MessageHandler Interface needs to be adapted to support both.

Sending logs to the clearing house seems to work.

Querying the ClearingHouse as another functionality still seems to return an internal server error as response, should be clarified.

Taken from Clearing-Module:
//TODO QueryMessages provoke HTTP 500 at clearing house

Currently, the connector developer typically builds a multipart-body-message with header and payload to pass the multipart-body on to us with the recipient info.

Since we will soon be supporting different transmission protocols, a general approach is needed here to become protocol-independent at this point for the connector-developer.

Currently, for implemented connector message-handlers, the complete payload input-stream of an incoming message is passed to the connector(-developer). Thus the Unified-Lib is independent of the IDS-MessageType of the incoming message, however, the connector developer must then deserialize the incoming message for the corresponding message type in the implementation of the connector instead.

It would be desirable to perform all serialization and deserialization in the Unified-Lib instead of leaving this to the connector developer.

As said in the title, "ids:trustStore" is redundant in some scenarios:
Certificates for server-keys and CAroot are often provided as *.pem files. When using docker, a automated keytool call like

keytool -import -storepass changeit -noprompt -trustcacerts -alias mkcert_development_ca -file $JAVA_HOME/lib/security/mkCertRootCA.pem -keystore cacerts

will integrate a rootCA for dev very nicely. Because the Framework is already able to read certs form the default store, the configmodel.json won't need a second truststore.

My current workaround: I've configured a truststore with a single dummy cert...

At the moment, the Unified-Lib roadmap includes support for Multipart, IDS-LDP/REST and IDSCPv2.
The untested MQTT-methods will be removed for now and rebuilt as needed in the further future.

In the current Interaction Libary the issuer of the JWT is chacked against a list of trusted issuers that are stored in the AppConfig file.
The IDS Messaging Service should access these values from the ConfigManager.

The code style needs to be rechecked again, after the further development in the meantime, against the current code-style state of the other IDSA repos around the DSC.

The internal names should reflect the new naming IDS-Messaging-Services

We need a name for the software artifact, what we are developing in the context of the Unified-Library project (IDS-Framework + Interaction-Library) and this repo itself.

Proposals so far:

• Joined/Combined/Merged IDS Framework
• IDS-Messaging-Services
• IDS-Messaging-SDK
• IDS-SDK
• SIML (Standard Info Model Lib)
• SIMU (Standard Info Model Utility)
• IDS Library
• IDS Framework

Currently, IDS-SDK seems to be quite popular.

We will probably tie this up in the next few meetings.

Other suggestions of course welcome at any time.