Implementation of a Java callout that performs WS-Security Signing and Validating it's failing

[pedrofrzmatos]

Hello community,

We have a configuration that is working with "1-14-0-apigee-2" but when we do the exact same configuration for version "1-14-0-apigee-3" it's failing.

https://github.com/DinoChiesa/Apigee-Java-WsSec-Signature-2

1-14-0-apigee-2 -> Apigee-Java-WsSec-Signature-2 -> Works
1-14-0-apigee-3 -> Apigee-Java-WsSec-Signature-2 -> Does not Works

What could be the potential issue here?

[pedrofrzmatos]

@dchiesa1 can you help me here?

{
"fault": {
"faultstring": "Failed to instantiate the JavaCallout Class com.google.apigee.callouts.wssecdsig.Sign",
"detail": {
"errorcode": "steps.javacallout.JavaCalloutInstantiationFailed"
}
}
}

[dchiesa1]

It sounds to me that one of the required dependencies is no longer present in 1-14-0-apigee-3 . 

In some cases when I publish a Java callout, I assume the dependencies, like BouncyCastle or slf4j, are available in Apigee.  You can see that in the pom.xml file of that callout , which has this snip in the ant plugin used during the package phase: 

            <!-- exclude files we can count on. -->
            <exclude name="lib/slf4j-api-${slf4j.version}.jar"/>
            <exclude name="lib/bc*-jdk15on-*.jar"/>

In the case of this particular callout, the required jars are:

bcutil-jdk15on-1.70.jar
slf4j-api-1.7.14.jar
bcpkix-jdk15on-1.70.jar
bcprov-jdk15on-1.70.jar

Strictly speaking , excluding dependencies like this from the packaging phase is risky. Apigee doesn't make any guarantees that it supplies a set of  "common" or "popular" Java JARs  for use by callouts.  Apigee of course is built on Java and uses many JARs itself, and at least up until now, the JARs Apigee packages for itself could also be used by callouts. But there has been no guarantee. 

The Apigee documentation has always said that you must explicitly provide all dependencies for any JARs you use in JavaCallouts. For years, those JARs have been available and have been resolvable, so it hasn't been a problem.  I am not familiar with the payload for 1-14-0-apigee-3 , but I suppose it is possible that one or more of those JARs are no longer available. 

If this is the problem , then the solution is one of these things: 

• manually obtain the Bouncy castle jars and slf4j jars 
• comment-out those two lines from the pom.xml file,  and rebuild the callout jar. This will assemble all the JARs necessary for this callout, and place them into the bundle/apiproxy/resources/java directory. 

...and THEN, you must  supply those jars as resources in your environment, or (probably less wise) as resources for this particular proxy. 

There is another possibility, and that is that the security permissions have changed in 1-14-0-apigee-3 ., and those permissions now prevent loading of classes that previously were permitted.

That seems less likely.  I haven't read any release notes.  Maybe you have?  

[dchiesa1]

There have been some changes the the Java Security policy handling, recently. I cannot tell if these changes

• are included in 1-14-0-apigee-3 and not present in 1-14-0-apigee-2
• would cause the behavior you are  seeing

In any case my suggestion above still applies: supply all the JAR files.

@Veronique FYI

[dchiesa1 · Accepted solution]

After further review, I think it may be that something has changed in 1-14-0-apigee-3 that prevents this class from loading. It is not about the dependencies.  

Can you try this, as an experiment?  Try using the Jar from this branch of the repo::
https://github.com/DinoChiesa/Apigee-Java-WsSec-Signature-2/tree/remove-str-transform

Note- it is not the main branch.  You'll find a jar there dated 20250104 . Try that. (You will need to update your Java callout policies to refer to this new jar).

[pauljosh]

Hi @dchiesa1 good day! 

At the present, I've tested all 3 versions of the JAR (main branch, remove str transform branch and fix str transform branch)

Can you kindly help advise if there are latest updates on 1-14-0-apigee-4 that may be affecting the updates done to the JAR? 

This error still persists for my case "Failed to instantiate the JavaCallout Class com.google.apigee.callouts.wssecdsig.Validate"

Thank you in advance! 

[dchiesa1]

I don't know. Can you ask a new question and provide complete details there?  you wrote " if there are latest updates on 1-14-0-apigee-4 that may be affecting the updates done to the JAR? " 

I don't know what you're getting at there, and it seems like a different topic than we had discussed with the other people on this thread.

[pauljosh]

Apologies for the confusion, I'll raise a new thread for this. 
Thank you! 

[pedrofrzmatos]

Hi @dchiesa1,

I already tried with that new jar successfully. 

Thanks for your help.
 

[AlexET]

Hi @pedrofrzmatos, Happy New Year! 🎉 I’m glad to read that @dchiesa1's guidance helped resolve your question. To assist others who might face a similar challenge, would you consider marking one of the responses as the accepted solution?

Thank you for contributing to the community.

[chandujubilee]

Hi Dino, 

Could you please help me here?

I've tried with old repo and updated repo(https://github.com/DinoChiesa/Apigee-Java-WsSec-Signature-2/tree/remove-str-transform) , I'm getting below error in both the cases 

Thanks!!

[dchiesa1]

It looks to me that your local build environment is not able to access the registry where you can download the Apigee jars (message-flow and expressions) and their dependencies. There could be multiple reasons for this. 

• The most likely, in an Enterprise, is that there are security restrictions in place that prevent builds from pulling jars or artifacts from arbitrary repositories.  Your build system (your development workstation, or your automated build server, whichever is applicable to your scenario) needs to be able to retrieve from the maven repo.  In the case of Apigee, Google has made these available, not in maven central (not https://repo.maven.apache.org/maven2/ ) but in an Apigee-specific repo, with the base URL https://us-maven.pkg.dev/apigee-release/apigee-java-callout-dependencies . 
  And for the artifacts like "message-flow", maven will try to perform a GET on this URL :
  https://us-maven.pkg.dev/apigee-release/apigee-java-callout-dependencies/com/apigee/gateway/librarie...
  
  The structure is: {baseUrl}/{dotswap(groupId)}/{artifactId}/maven-metadata.xml , where "dotswap" implies swapping all the dots for slashes in the groupid.  The groupId for Apigee jars is com.apigee.gateway.libraries . 
  
  To check this on your own, manually, I would suggest 
  curl -V https://us-maven.pkg.dev/apigee-release/apigee-java-callout-dependencies/com/apigee/gateway/librarie...
  
  

• Another possible problem is that for some reason your host machine does not trust the endpoint.  This seems less likely, in general, but the message I am seeing in your screenshot definitely indicates that maven does not trust the TLS certificates presented by the endpoint. 
  
  You can show the certs from the remove endpoint by invoking this in a bash shell:

  TARGETHOST=us-maven.pkg.dev
  TARGETPORT=443
  openssl s_client -connect ${TARGETHOST}:${TARGETPORT} -servername ${TARGETHOST} -showcerts

  On my machine, that shows me that the final cert in the chain is C=US, O=Google Trust Services LLC, CN=GTS Root R1 , which is something that must be present in your local truststore .  It seems likely that it would be; but if there is some network proxy between your build server and the internet, then , maybe not.  Or, maybe that intervening server is presenting a different set of certificates. Check it. 

Let me know.