Skip to Content
Author's profile photo Dong Pan

Integrating 3rd-party Cryptographic Providers into NetWeaver Java – What’s Possible and What’s Not

Since you are now reading this blog post, I bet you are a security guru who knows that IAIK is the primary cryptographic provider used in SAP NetWeaver Java. But, is it possible to use a 3rd-party crypto provider to carry out the cryptographic tasks that are usually performed by IAIK? The answer is: it depends, but in many typical scenarios, yes.


Before we dive into all the security concepts and jargons, let’s first step back and take a look at why you would need a 3rd-party crypto provider. Here are some of the reasons:

– Legal reasons (e.g., export AND import restrictions)

– Government/Corporate regulations

– Special crypto algorithms/key length required that are not provided by IAIK


*IMPORTANT NOTE: the following steps to plug in 3rd-party cryptographic providers into NetWeaver J2EE engine may result in breaks or malfunction in standard software functionalities, due to the fact that each cryptographic provider may behave differently even though they may all comply with the JCE specification. Therefore it is your responsibility to make sure that software components on the NetWeaver J2EE engine continue to function normally after plugging in the 3rd-party cryptographic provider. This article is provided AS IS and provides no warranty whatsoever. Since the 3rd-party cryptographic providers are not tested/certified by SAP, issues arising from the below steps will not be supported by SAP.


The Theory 

Now let’s get started. First of all, a quick recap of how Java cryptographic provider works with the JVM.


The Java Cryptography Architecture (JCA) was designed to offer implementation independence, so that you can use cryptographic services without worrying about the implementation details. This is achieved by using a “provider”-based architecture. A Cryptographic Service Provider is a basically a package or a set of packages that implement one or more cryptographic services, such as digital signature algorithms, message digest algorithms, and key conversion services. Java programs can use Cryptographic Service Providers in two ways:

1) Refer to generic Java security objects (such as a Signature object) without knowing which underlying Cryptographic Service Provider is in use.

2) Refer to provider-specific security objects explicitly to take advantage of provider-specific crypto features.


Therefore whether you can safely plug in or replace a Cryptographic Service Provider in any Java-based application server depends on:

1) Whether all the Java programs are based on generic Java security objects

2) Whether the new crypto provider implements all the cryptographic services that are used by the Java programs.


For more details about JCA and JCE (Java Cryptography Extension), refer to the JCA API specification and reference:


How does SAP Java-based applications use cryptographic objects?

Well, it is simply impossible to check all Java-based applications released so far. However we can easily check out some frequently used scenarios, especially the fundamental APIs that are used by most applications, such as:

– SAP Logon Ticket API

– Digital Signatures and Document Encryption API, a.k.a. SSF API


SAP Logon Ticket is the foundation of the most frequently used Single Sign-On mechnism. It is based on digtal signature technology and its implementation uses generic Java security/cryptographic objects. Therefore, as long as the 3rd-party provides the same digital signature services required by the Logon Ticket API, you can plug it in.


The Digital Signatures and Document Encryption API is a Java implementation of SAP’s standard Secure Store and Forward (SSF) mechanisms. It is widely used in both NetWeaver and Business Suite applications to protect sensitive documents. Currently it supports the following three formats:

– PKCS#7

– S/MIME v2



Unfortunately the PKCS#7 and S/MIME formats rely on direct reference to IAIK libraries; however the XML format, which is used most nowadays, is based on generic Java security/crypto objects. So as long as your 3rd-party crypto provider offers the crypto services required for SSF-based XML security, it is safe to plug it in.


You might want to ask, “what about SSL/HTTPS?” Although this seems to be normal scenario, in reality, it is not. There is typically a reverse proxy or load balancer sitting in front of the J2EE engine, offloading SSL overhead from the J2EE engine. How to use a 3rd-party crypto provider on the reverse proxy or load balance is out of the scope of this article.


See It in Action

Now I would like to show you an example in which the Bouncy Castle crypto provider will be plugged into NetWeaver J2EE engine 7.01 SPS05. The crypto provider will then be used for SAP Logon Ticket generation/verification and XML security.


First, you would need to get a copy of JCE-compliant crypto provider from your vendor. In my case, the Bouncy Castle crypto library can be downloaded from Make sure the crypto library is compatible with JDK 1.4.2.


Then you can choose whether you want to add the crypto provider statically or dynamically.  If you would like to add it statically, you can copy the library to $JAVA_HOME$/jre/lib/ext and edit $JAVA_HOME$/jre/lib/security/ (see more details in the JCA API Specification and Reference mentioned above). In the below steps, I will use the dynamic approach for better flexibility. 


In the next step you will need to include the crypto library in your J2EE application/service development project, and deploy it to the J2EE engine. Make sure you set it with priority 2 so that IAIK is right after it. Do not set it to 1 because that is reserved for the Controlled Provider (by SAP) which performs housekeeping tasks. The following code snippet shows how to add the Bouncy Castle crypto provider with priority 2. bcProvider = new org.bouncycastle.jce.provider.BouncyCastleProvider(); , 2);


You can now verify whether the crypto provider is inserted successfully. Launch Visual Administrator, and go to server->services->Security Provider->Runtime->Cryptography Providers. The newly added crypto provider should be listed in the second place, as shown in the below figure:



Note that we are not trying to remove the IAIK library. Instead we are only lowering its priority so that the 3rd-party crypto provider becomes the preferred provider for your application, IF it provides the crypto services required (otherwise the JVM will go down the priority list until it finds the first provider that offers the service). We have to keep IAIK for applications that explicitly reference IAIK, and for applications that rely on the crypto services provided only by IAIK.


So how do we know whether the 3rd-party crypto provider is indeed in use? Remember that listing the crypto provider with the highest priority doesn’t necessarily mean it will get used. Let’s run some tests to confirm that Bouncy Castle crypto provideris actually in use. To do that, I instrumented the Bouncy Castle crypto library with CA Wily Introscope. As a result, I can turn on Wily Transaction Tracer to monitor whether the Bouncy Castle crypto provider is invoked by a particular user session. If you are not familiar with Wily Introscope, take a look at the Wily Introscope User Guide at


Test No. 1 – SAP Logon Ticket Creation
In this test I logged on to the Enterprise Portal. I turned on Wily Transaction Tracer right before I entered the user credentials. Check the below figure of Wily trace and you will see that the CreateTicketLoginModule, the login module which generates Logon Tickets with digital signature upon logon, implicitly called the Bouncy Castle crypto library.





Test No. 2 – SAP Logon Ticket Verification

In this test I logged on to the Enterprise Portal with a logon ticket obtained from another SAP system that the portal trusts. In the below figure of Wily trace, you can see that the EvaluateTicketLoginModule, the login module that verifies the digital signature of the ticket, implicitly called the Bouncy Castle crypto library.




Test No. 3 – Saving Portal User Mapping Data with Strong Encryption

In this test I am trying to store Portal User Mapping data on the portal which has Strong Encryption for User Mapping turned on. In the below figure of Wily trace, you can see that the user mapping data encryption implicitly called the Bouncy Castle crypto library.



Test No. 4 – Digitally Sign an XML document
In this test I will use a small WebDyrnpo application to digitally sign an XML document twice with the standard SSF API, using SHA and MD5 digest algorithms, respectively. The key pair used is retrieved with standard keystore API from the J2EE keystore which was created by Visual Administrator.


In the below figure of Wily trace, you can see that the SsfDataXML.sign() method implicitly called the Bouncy Castle crypto library.




Test No. 5 – Encrypt an XML document
In this test I will use a small WebDyrnpo application to encrypt an XML document with the standard SSF API, using the DES_EDE3_CBC algorithm. The key pair used is the same as in the last test.


Here is the code snippet used for XML encryption: data = new ;


boolean res = data.encrypt(signer, pab, “DES_EDE3_CBC”);


In the below figure of Wily trace, you can see that the SsfDataXML.encrypt() method implicitly called the Bouncy Castle crypto library.




Depending on your overall usage scenario, it is possible to make use of a 3rd-party cryptographic provider on your NetWeaver J2EE engine in many typical cases, such as logon ticket-based Single Sign-On, standard SSF-based XML signature/encryption (and all the functionalities which are built upon XML signature/encryption), as long as your crypto provider supports the crypto services required.


It is worthwhile to reiterate that plugging a cryptographic provider into your NetWeaver J2EE engine has a global impact on all functionalities that rely on cryptography, explicitly or implicitly. Not all crypto provider behaves the same way – expect compability issues. So think twice before you decide to use a 3rd-party crypto provider. Work out a comprehensive test plan before making the change in your production systems.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Tong Zheng
      Tong Zheng
      Thank you Dong for presenting us such a nice article. It is very exciting to know that now in JEE engine we have a interchangable crypto lib based on JCE standard. This brings a lot more extensibility of SAP JEE when coming to adapt to certain local regulations not to use an imported crypto lib. Now I am more concerned about the testability of the plugged in library. How can we build a complete test case to make sure this new library will work flawlessly with SAP JEE? I believe we have some interesting topics to explore in this regard.
      Author's profile photo Otto Frost
      Otto Frost

      Thanks for the article.

      It seems like a good way to get problems. You don't want a BC security provider globally in AS java, Most applications requires different versions of BC, and BC versions are not compatible.

      I suggest using the technique proposed in snote

      1049845 - How to use custom security providers

      String currentProvider = ControlledCryptographyProvider.useProvider(<non-IAIK-provider-name>);

      try {

        // use non-IAIK crypto imlementation here

      } finally {



      Is the SAP note correct? Maybe the following should be used to revert back? 


      I think SAP should have used the 1049845 - How to use custom security providers when implementing the SAP PI B2B addon with sftp/pgp/as2, the same applies to the seeburger as2 adapters, aedaptive pgp and others, instead the mentioned adapters are incompatible and can't reside in the same server.

      Aedaptive claims to have fixed there adapters but SAP and Seeburger have not.

      Author's profile photo Former Member
      Former Member

      Hello Otto,

          do you know if I can change the security provider in a java mapping for PI 7.11 ?

      This note isn't that much clear. What jar do I need to use that class?

      Any hints would be great.

      Thanks in advance.

      Author's profile photo Otto Frost
      Otto Frost

      Sorry, I have not tested it for java mapping but I guess it should work. I usually use to find jars containing classes.

      If you have seeburger, sap b2b sftp/pgp or aedaptive adapters you are gone.

      The all load bouncy castle security provider as global, but in different versions which are not compatible.

      Author's profile photo Former Member
      Former Member

      That is a great program (jfind)!

      I found the class ControlledCryptographyProvider in the

      Now let's see if I can make this work...


      Author's profile photo Renat Khamidoulin
      Renat Khamidoulin

      Hi Federico,

      Could you please share your experience in implementation of custom security provider inside a PI java mapping?

      Do you succeed with

      Any help in this area would be great.

      Thanks in advance.

      Author's profile photo Former Member
      Former Member

      Hello Renat,

      Finally I used the libs to select the Provider I needed from inside my java mapping for PI 7.11.

      It was much simpler than I thought.

      Provider provider = Security.getProvider("SunJSSE");

      You need to import and

      No need for external jars.

      You can verify the Provider with:

      getTrace().addDebugMessage("provider.getName=" + provider.getName());

      getTrace().addDebugMessage("provider.getInfo=" + provider.getInfo());

      getTrace().addDebugMessage("provider.className=" + provider.getClass().getName());

      Hope it helps.