| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Per default, integration tests are excluded from build. They can be
included with the `-P integration-test` argument.
- Pom: Add maven profile for integration tests.
- Rename integration tests (add `IT` prefix).
- Move Resources into IT* folders.
- Add MsgClientTest to test suite and add assertions to each test case.
|
|
- Move JaxbM initialization into Marshaller such that it can be used
in tests without Spring's Application Context.
- Remove SpringRunner from Mzs2MsgConverter Test, which makes the test
run faster.
|
|
- Also: Ensure that truststore is of type JKS because PKCS12 is not
supported.
|
|
- Print a big scary warning message for everyone who enables "trustAll"
- Test TrustAll and LaxHostNameVerification
- Describe test case requirements and add key material needed to run
these test cases.
|
|
- Refactor: Get rid of MsgClient, because MsgClientFactory can do all the work.
- Add Connection Timeout and Request Timeout (Policies of HTTP Client)
to mzs:DeliveryRequest/Config and application.yaml.
- Update readme: Add JDK 12 Requirement
|
|
- Switch to java 12 for now. Reason: Bug [1] in JDK 11 (up to
jdk-11+28) impairs SSLHandshake ("Unsupported Operation Exception"),
but was fixed in Java 12.
- Set HTTP policy to infinite.
- Fix key/truststore path resolution
- Fix NPE in ConfigUtil.merge
- Rearrange application.yaml to include two config profiles (one with
and one without SSL for the msg client).
- Add key material for testcases (Note: expires: May 2 14:47:08 2020 GMT)
- Update MsgClient Testcases
[1] https://bugs.openjdk.java.net/browse/JDK-8214098
|
|
- Add Component to create SSLContexts with own Key- and trust store.
- Inject SSLContext into HTTP Client.
- Add EAAF-Components Core Dependency, which is needed by
SSLContextCreator (KeyStoreUtils).
Schema Changes in mzs:DeliveryRequest/Config:
- Got Rid of mzs:DeliveryRequest/Config/Server. In mzs 1.4.1,
Server replaces the result of zkopf query person request. Since this
zkopf interface does not exist anymore, Server was removed.
- Add ClientType, which holds all parameters needed to connect to a
service (Url, SSL params, a.o.).
Configuration:
- Add default parameters for SSL Clients in application.yaml.
- Merge default parameters into incoming mzs:DeliveryRequests.
MoaZSException Fixes:
- Remove "Extends throwable" from Builder.
- Add convenient shorthand init method (message, throwable).
Refactor:
- Put "determinePath" to FileUtils.
- Put string related utility functions into StringUtils.
|
|
|
|
- Interpret `ISignatureVerificationService` response properly (by
following security layer spec [1] and moaspss handbook [2]).
- Add config flag `moa.spss.is-manifest-check-active`
- Change SignatureVerifier Interface: Remove @return boolean, just
throw an exception when a validation error occurs. Reason: In case
the signature cannot be validated, the application always needs the
reason for the validation error, which requires the verifier to
throw an exception. In turn, the only valid return value for
`verify()` becomes `true`, which can be omitted at that point.
- Add testcase for verifying a valid enveloped xml signature
- Remove Certificates that are not needed.
[1] https://www.buergerkarte.at/konzept/securitylayer/spezifikation/20140114/core/core.html
[2] https://apps.egiz.gv.at/handbooks/moa-spss/handbook/handbook/usage/usage.html
|
|
|
|
Fixing "ASN.1 creation error: iaik.asn1.CodingException: Length: Too
large ASN.1 object: 109"
- Set fallback value ('jks') for system property
'javax.net.ssl.keyStoreType' and 'javax.net.ssl.trustStoreType'. If
system property is not defined, MoaSigConfig falls back to value
from spring environment. Reason: Without this property explicitly
set to JKS, the inclusion of eaaf-components-moa-sig-lib breaks the
HTTP client builder and the ASN.1 creation error arises. See [1] for
explanation.
- Why fall back: Allows a user to configure these parameters via
command line, but gives meaningful defaults in case of absent
command line properties. Furthermore, these parameters can be configured via
application.yaml or .properties.
Others:
- Set fallback value for system property
'moa.spss.server.configuration'. If system property is not defined,
fall back to value from spring environment. Reason: Allows a user to
configure these parameters via command line while providing
meaningful defaults in case of absent command line properties.
- Add switch 'moa.spss.is-active' to enable / disable signature verification.
- Change log levels of at.gv.* and iaik.* packages to INFO
- Add default certstore (copied from EAAF Components).
- Add mzs root certificate to cert- and truststore.
- Update readme's installation requirements and guide.
Refactor:
- Extract public interface of SignatureVerification class.
- Rename trustprofile folder.
[1] Why eaaf-components-moa-sig-lib breaks HTTP client:
- Including eaaf-components-moa-sig-lib includes IAIK's jca/jce and
xsect, which in turn injects the iaik provider for cryptographic
operations and its own key store (iaik.pkcs.pkcs12.PKCS12KeyStore).
- The Apache HTTP client builder will ask for a
java.base/javax.net.ssl.SSLSocketFactory because it creates an SSL
context, even if the connection runs without SSL.
- Somewhere down the stack, this will trigger the TrustStoreManager to
hand over the systems default trust store (a JKS file) to IAIK's
PKCS12KeyStore. This happens if the type properties of the trust
stores are not set.
- Oracle relaxed a precondition of this trust store (somewhere in
between Java 8 and 11) in the TrustStoreManager: Formerly, the trust
store was a JKS object. Now, the trust store can be both a JKS and a
PKCS12 object. The TrustStoreManager expects the key store to handle
both types, and Oracle's keystore does. However, IAIK's key store
cannot handle a JKS object, but since eaaf-components-moa-sig-lib
was included, the IAIK key store comes first.
- PKCS12KeyStore expects a PKCS12 file but receives a JKS file ->
Parser Error.
|
|
- Ensure proper communication of errors between pipeline and mzs
service by converting MoaZSExceptions into DeliveryRequestStatus
messages.
- Revise MoaZSException: Add optional fields; those fields are a)
helpful to construct meaningful error messages and b) optional
because, depending on where an exception appears, either existent or
non-existent and thus optional. Add inner-class Builder.
- Integrate Signature Verification into pipeline and add Stub for
SignatureVerification.
- Move TNVZResponse's Mimetype check into dedicated class (Reason:
separate abstration layers).
- Update api changes in testcases.
|
|
- Add egovutils dependency (Reason: Need DomUtils to serialize /
unserialize Soap Message via DOMParser)
- Add Incerceptor to MsgClient / -Factory that stores the message
content byte-by-byte in the DeliveryRepository. The format is
required for successfully validating a DeliveryRequestStatus.
- Add SoapUtils, which interacts with byte[] Soap message.
- Add CXFMessageUtils, which interacts with CXF Messages from
interceptor chains.
- Refactor xsd namespaces: Move them out from the PrefixMapper and
into a dedicated class.
|
|
- MZS cant reply with a msg:DeliveryRequestStatusType to a
mzs:DeliveryRequest. Reason: unmarshalling a
msg:DeliveryRequestStatusType with JAXB (after receiving the msg
reply) breaks the signature in msg:DeliveryRequestStatusType. Why?
Because JAXB marshalling tinkers with the namespaces and, as for the
current state of knowledge, we cannot configure the JAXB marshaller
to reconstruct a XML Document byte-by-byte such that a signature
that went through this process can be verified successfully (see [1]).
- For this reason, we revert back to mzs:DeliveryResponse and add new
fields / remove obsolete fields / capture all changes between zusemsg
1.5.3 and zusemsg 2.0.0.
- The easier solution would be to wrap and transmit signed data +
signature in a binary (base64) container, such that apache cxf and
other web service frameworks won't unmarshall them. This doesnt work
because zusemsg 2.0.0 is final.
app2mzs.xsd Changes in Detail :
- Add DeliverySystem, ZSDeliveryID and GZ to MessageType (MessageType
is the base type of DeliveryResponse.Success, -PartialSuccess, and
-Error); Reason: It was added to zusemsg 2.0.0.
- Add SignedDeliveryRequestStatus to MessageType. Reason: If msg
returns signed reply, this element contains the reply as byte[] such
that the signature does not break.
- Add optional PreadvicenoteSend to ErrorType (because it was added in
zusemsg 2.0.0)
- Remove MZSDeliveryID from every instance because this ID does not
exist anymore (moa zs does not maintain requests in a database).
- Remove DocumentReference from ErrorType as it was removed from
zusemsg 2.0.0.
- Remove DeliveryConfirmation as node in DeliveryNotificiationType
because it does not exist anymore in zusemsg 2.0.0;
DeliveryConfirmation is also obsolete because all msg' replies are
signed and need to be transferred to the sender application as a
byte[], which is done by SignedDeliveryRequestStatus node in
MessageType.
- Remove DeliveryStatement as node in DeliveryNotificiationType
because it does not exist anymore in zusemsg 2.0.0.
Other Changes
- Adapt codebase: MzsService returns mzs:DeliveryResponse.
- Implement conversion from msg:DeliveryRequestStatus to
mzs:DeliveryResponse.
- Add store / retrieve interface to DeliveryRepository that stores
signed delivery request statuses as byte[].
Temporary Changes
- Disable integration tests which have external dependencies.
[1] https://download.oracle.com/javaee-archive/jaxb.java.net/users/2007/03/6674.html
Signed-off-by: Christof Rabensteiner <christof.rabensteiner@iaik.tugraz.at>
|
|
- Refactor MsgClient: Not a Singleton anymore. Use MsgClientFactory to
make a client. Make request and config private fields.
- Add configuration parameters to application.yaml.
- Init SSL client auth testcase, but dont include in testsuite because
it aint working yet.
|
|
|
|
- Reason: All three classes opertate with the same data type, have
the same clients, and have the same reasons for change.
- Makes code in client more readable as it reduces number of
dependencies.
|
|
Refactor
- Add Builder to ConfigProfileGenerator. Reason: Constructor had too
many arguments.
- Move Conversion from Map to Config from ConfigProfileGenerator into
dedicated 'ConvertMapToConfig' Class; Reason: I expect additional
configuration properties and I don't want those changes to affect
the ConfigProfileGenerator (or it's test cases)
- Move Access to Spring's env into facade to simplify ConfigProfileGenerator.
|
|
|
|
ConfigProfileGenerator:
- Cancel startup if default Config profile is incomplete.
- Add property flag
'verify-completeness-of-default-delivery-request-configuration',
which allows admin to disable completeness check. In that case, just
log a warning if the default profile is incomplete.
Augmenter:
- Ensure that after merging the config is complete (or throw an
exception otherwise).
- Refactor: Move ConfigProfileValidator from ConfigProfileGenerator to
dedicated "ConfigProfileValidator" class; Reason: Augmenter needs to
check completness of at-runtime-compiled configuration.
- Refactor: Rewrote code for better readability.
Others
- NPE Fix in ConfigProfileMerger: If FallbackConfigProfile/Server is
empty, use PrimaryProfile/Server.
|
|
Config Profile Integration:
- Merge generated Configs from ConfigProfileGenerator with the default
Config; Reason: Merging profile Configs with default Config asap
ensures that profile Configs are "as complete as possible" while
allowing profile Configs to "on-demand"-override values from the
default Config.
- Adapt Augmenter to work with Config profiles: Select a Config on the
basis of on msg:DeliveryRequest/Config/ProfileId, fall back to 'default'
Config.
- Schema change: Make ProfileID optional.
Refactoring:
- Move Config-merging code from Augmenter into dedicated
'ConfigProfileMerger' class.
- ConfigProfileGenerator: Clarify stream pipeline and comply with
coding standard w.r.t. constant members.
- Add Augmenter test cases for profile selection.
|
|
Augmenter
- Replace default Config Profile with map of Config Profiles. Now,
Augmenter can choose a config profile at runtime and augment it.
- Move Augmenter to sub package.
WIP
- Implement ConfigProfileGenerator, which retrieves Config profiles
from Spring Environment and returns an easy-to-use map with
profiles that is keyed with profile id's.
- Replace application.properties with application.yaml.
- Remove Augmenter test cases: They need to be adapted.
|
|
|
|
- Rewrite DeliveryRequestAugmenter to allow per-field-overriding of
configuration parameters and add test suite.
- Mzs schema change: Move DeliveryRequest/Server into
DeliveryRequest/Config; Reason: DeliveryRequest/Config contains all
parameters exclusively needed by moazs to execute the delivery
request. The msg's server url belongs to this set of parameters.
- WIP: Add prototype implementation of MsgClient and move MsgClient to
dedicated package.
- Refactor: move TnvzClient to dedicated package.
|
|
- Refactor: Move TnvzClient in sub package
- Autowire all parameters instead of each parameter individually
|
|
|
|
- Relax Validation for now by only validating incoming requests.
|
|
Problem: Apache CXF does not validate incoming mzs:DeliveryRequests
automatically. Per default, validation is off (performs better).
However, (1) we need to validate incoming requests, and (2)
automated CXF validation requires less maintenance and is
expected to be more stable than manual validation.
Solution:
- Add @SchemaValidation annotation to @Service.
- Endpoint Configuration: set WsdlLocation and ServiceName (needed
to prevent parser errors; see [1]).
Without those, CXF validates against generated classes and not
against the WSDL spec, and generated classes do not contain format
restrictions.
Add a testcase with an invalid delivery request ("rejectBothProfile-
AndCorporateBody") to ensure that the validator works.
[1] https://stackoverflow.com/questions/2231779/cxf-and-validation-schema-restrictions-ignored
|
|
|
|
- Reason: Converter does not perform validation
|
|
|
|
- Implement own NamespacePrefixMapper that maps prefixes depending on
whether a msg or a mzs object is being marshaled.
- Namespaces are not hardcoded but extracted from jaxb's generated
sources (somewhat indirect, can be considered a hack, but there's no
public API to extract namespaces)
|
|
- Implement and test conversion from mzs:DeliveryRequest to
msg:DeliveryRequest with the "convert-pojos-by-hand"-strategy.
Reason: The chosen strategy benefits from JAXB's strong typing,
which is useful in this scenario: Differences between msg and mzs
are nuanced and easy to overlook. The chosen strategy is,
unfortunately, verbose and could become expensive to maintain.
- Update SameThreadDeliveryPipeline: Integrate tnvz query, conversion,
and msg query.
- Add MsgClient stub.
tnvz:
- Change TnvzClient stub interface.
- Implement mimetype mismatch check from tnvz Response.
- Put p:Identification from tnvz response into msg:DeliveryRequest.
MZS Schema changes:
- Replace DeliveryRequest/Sender/Person with CorporateBody (because
thats the only sender that is allowed by zusemsg) and add a
SenderProfile choice.
- Add ID Attribute to DeliveryRequest/Sender because
msg/DeliveryRequest/Sender/AbstractSenderPersonType also has an id
attribute.
- Remove PersonDataType because it's dead code.
|
|
- Reason: Improves readability and makes import statetemens shorter
and more consistent
|
|
- App2MZS Server: Instead of generating a DeliveryRequestStatus/Error
Message, we throw an exception. This will generate a SoapFault
(including a 500 http status code), which is more appropriate.
- Fix possible NPE of deliveryRequest.getMetadata().getAppDeliveryID()
by moving appDeliveryID initialization into the TimeOutException catch block
- pom.xml: Remove hamcrest dependency, as not needed for now.
|
|
Add Optional "Config" to MZS Schema:
- Add mzs:DeliveryRequest/Config Element with a
"PerformQueryPersonRequest" node
- The config element contains parameters that are interpreted by
moa-zs and not forwarded to the ZD
- The boolean PerformQueryPersonRequest tells moa-zs if moa-zs should
perform a QueryPersonRequest towards the TNVZ.
- If config is missing, moa-zs augments the delivery request with
parameters from the app's configuartion or the default configuartion
Other Changes:
- Validate and augment incoming requests with the
DeliveryPreprocessor.
- Add stub for TlnvzClient.
- Remove some leftover ObjectFactory imports (because of the builder
they are not needed anymore)
Fixes
- Fixed incorrect API usage of Messageformat.format: format string
needs an index.
pom.xml
- Add Hamcrest Dependency (for writing more expressive tests)
- Add copy constructor to JAXB Builder
Testing
- Test validation of incoming request
- Refactor testcases to improve readability
|
|
- Use Immutable-XJC from https://github.com/sabomichal/immutable-xjc
- Update existing JAXB-object manipulations to use the Builder
- Remove jaxbMarshallerTest (as it relies on mutable JAXB interfaces)
Reason for making JAXB objects immutable: I put JAXB objects in the
repository. Depending on the configuration, the repository can be a
simple hashmap; in that case I might end up sharing JAXB objects
between threads. Immutable shared object should make life a little
simpler.
|
|
- Reason: App2MzsServiceTests only run through the app2mzs front end
without doing any pipeline work.
|
|
- Change app2mzs interface: output message from
app2mzs:DeliveryRequest was app2mzs:DeliveryResponse, now its
msg:DeliveryRequestStatus. Reason: ZD returns
msg:DeliveryRequestStatus which is signed. Moazs does not convert
msg:DeliveryRequestStatus into app2mzs:DeliveryResponse because the
conversion woudl break the signature.
- App2MzsService: Make beans final and inject them with constructor;
Refactor DeliveryRequestHandler into App2MZSService.
- DeliveryPipeline: Add Interface and a "SameThreadImplementation"
that executes the pipeline in the same threat and can be used in
single mode.
- DeliveryRepository: Augment interface for storing and retrieving
request status objects; Add in-memory-implementation for status objects.
- Utils: Add helper function for coalescing multiple values
|
|
|
|
- Important Fix: I forgot to annotate App2MzsService with @Service and
autowire the App2MzsService object when creating the endpoint
bean. For this reason, Spring did not autowire the dependencies in
App2MzsService and I ended up with NullPointerExceptions in the
testsuite.
- Updated some more namespaces
- Add objectFactory bean. objectfactory is autogenerated via the
cxf-code-generation plugin, so i cannot annotate it with @Component
or @Service. Alternative: create the @Bean by myself
- Update the validDeliveryRequest SOAP Message to match the mzs 2.0.0
scheme.
|
|
|
|
- Unit test makes a http request to the service
- Fix NPE by adding endpoint.setAdress("/")
- Choose better name for App2MzsService
|
