[
https://issues.apache.org/jira/browse/WSS-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved WSS-264.
-------------------------------------
Resolution: Fixed
Fixed for 1.6 - I'm leaving the 1.5.x branch alone for backwards compatibility
reasons. I've changed the configuration in the 1.6 pom to:
<DynamicImport-Package>
org.bouncycastle.jce.provider,
org.apache.ws.security.components.crypto,
org.apache.ws.security.saml
</DynamicImport-Package>
Juice is not used in 1.6 so we don't need to include it. These imports cover
BouncyCastle, the default Crypto implementations, and the default SAML Issuer
implementations. Any third-party implementations will need to be specified as a
fragment, as you have outlined. The same goes for any CallbackHandler
implementation that is to be loaded by WSS4J.
Colm.
> OSGi bundle should NOT specify the universal DynamicImport-Package: *
> ---------------------------------------------------------------------
>
> Key: WSS-264
> URL: https://issues.apache.org/jira/browse/WSS-264
> Project: WSS4J
> Issue Type: Improvement
> Components: WSS4J Core
> Affects Versions: 1.5.10
> Reporter: Ancoron Luciferis
> Assignee: Colm O hEigeartaigh
> Fix For: 1.6
>
>
> WSS4J is about security and so should the OSGi bundle at the class loading
> level.
> In version 1.5.10 you are using this Manifest header:
> DynamicImport-Package: *
> which resolves all class loading issues but effectively disables the benefit
> of OSGi in terms of class visibility.
> So please put some effort in here to get only those packages listed that may
> eventually being accessed at runtime.
> A simple search yields only these classes for dynamic loading:
> org.bouncycastle.jce.provider.BouncyCastleProvider
> org.apache.security.juice.provider.JuiCEProviderOpenSSL
> ...so the header could be:
> DynamicImport-Package:
> org.bouncycastle.jce.provider,org.apache.security.juice.provider
> I also see that configuration properties like
> "org.apache.ws.security.saml.issuerClass" in the SAMLIssuerFactory class may
> introduce problems herewith but after all there are 2 solutions:
> 1.) the implementor rebuilds the WSS4J bundle and adds an appropriate dynamic
> import
> 2.) the implementor packages the implementation class inside a fragment
> bundle attaching to the WSS4J host bundle
> Option 2 is much more elegant, keeps package/class visibility at a minimum
> and also does not require to customize the WSS4J OSGi bundle.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
