Hi, Looks like JCA provider loading already leverages ServiceProvider’s under the hood:
https://github.com/openjdk/jdk/blob/0866799ca8f9540de5b2eee2720960160995a10f/src/java.base/share/classes/sun/security/jca/ProviderConfig.java#L290-L353 But probably called too early to discover providers contributed via dynamically loaded bundles. However, it should be possible to come up with some helpers based on https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.loader.html to discover providers and register them manually via https://docs.oracle.com/javase/8/docs/api/java/security/Security.html#insertProviderAt-java.security.Provider-int-. I will try to investigate a bit. Konrad > On 22. Jul 2026, at 14:22, Konrad Windszus <[email protected]> wrote: > > Hi Robert, > Thanks for your input. However JCA supports pluggable providers. So by having > an implementation based on JCA in Sling one could either use: > > a) JRE built in providers like SUN JCE > b) third party providers like Bouncycastle > > Using b) would require to have some kind of class loading compliant with OSGi > for the providers > (https://docs.oracle.com/javase/8/docs/api/java/security/Provider.html), but > I hope to be able it is possible to have something pluggable and > discoverable, so that it works out of the box. > In the worst case we need to have some glue code, i.e. a Factory for > https://github.com/apache/sling-org-apache-sling-commons-crypto/blob/master/src/main/java/org/apache/sling/commons/crypto/CryptoService.java > which takes a provider as argument in order to use providers not being > exposed from the System Bundle (i.e. JRE). > > Does anyone know if there is specific OSGi support for provider discovery > outlined in > https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html > -> > Registering the Provider? > Dynamically registering a provider via > https://docs.oracle.com/javase/8/docs/api/java/security/Security.html#insertProviderAt-java.security.Provider-int- > is IMHO not yet supported via some OSGi helper class (similar to > https://aries.apache.org/documentation/modules/spi-fly.html) so that is > something which needs to be written as well. > > Then one could use the provider from Commons Crypto via > https://docs.oracle.com/javase/8/docs/api/java/security/Security.html#getProvider-java.lang.String- > (identified via name) to specifically select a dedicated provider (like > Bouncycastle) without necessarily replacing the JRE default (SUN JCE). > > Regards, > Konrad > >> On 22. Jul 2026, at 12:24, Robert Munteanu <[email protected]> wrote: >> >> Hi Konrad, >> >> On Wed, 2026-07-22 at 10:29 +0200, Konrad Windszus wrote: >>> Hi, >>> Unfortunately Jasypt used in Commons Crypto >>> (https://sling.apache.org/documentation/bundles/commons-crypto.html) >>> is no longer maintained: >>> >>>> This library is no longer maintained, but it is kept here for >>>> historical reference. A lot of effort went into it back in the day, >>>> and I wouldn't want to just delete it. >>> >>> (From https://github.com/jasypt/jasypt/blob/master/README.md) >>> >>> Would it make sense to come up with an implementation based on the >>> JCA >>> (https://docs.oracle.com/javase/8/docs/technotes/guides/security/cryp >>> to/CryptoSpec.html#ProviderArch) >>> That way one would have the option to pick between different >>> providers. The default one shipping with most JREs ("Sun JCE >>> provider, >>> https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJCEProvider >>> ) already provides quite some algorithms. >>> Bouncycastle is an alternative provider supporting even more >>> algorithms: >>> https://www.bouncycastle.org/documentation/specification_interoperability/#algorithms-and-key-types >>> . >> >> Yes, I think it makes a lot of sense to move away from Jasypt. I have >> no strong opinion on whether we should use JCA or Bouncycastle. >> >> Thanks, >> Robert >> >>> >>> In the end I would like to hook this up with CACs >>> (https://sling.apache.org/documentation/bundles/context-aware-configu >>> ration/context-aware-configuration.html) so that a property is >>> optionally only stored in an encrypted fashion (right now this is >>> always stored as plain text JCR property which is not suitable for >>> secret data). >>> >>> WDYT? >>> Konrad > >
