[
https://issues.apache.org/jira/browse/KARAF-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15466624#comment-15466624
]
Xilai Dai commented on KARAF-4520:
----------------------------------
@Freeman, A problem we have after upgraded to Karaf 4.0.6/CXF 3.1.7 may related
to this changes.
When the use execute some commands from client/ssh of karaf, and the cxf-core
bundle got refreshed/uninstalled in the container, the
org.apache.karaf.shell.ssh will be refreshed consequently. this will break the
command execution and throw ssh exception. (cxf-core is very easy to be
refreshed in our container)
The cascading bundles refresh as below (Karaf 4.0.6/CXF 3.1.7)
{code}
Uninstalling bundles:
org.apache.cxf.services.sts.core/3.1.7
Refreshing bundles:
org.apache.cxf.cxf-core/3.1.7 (Wired to
org.apache.cxf.services.sts.core/3.1.7 which is being refreshed)
org.apache.karaf.jaas.modules/4.0.6 (Wired to org.apache.cxf.cxf-core/3.1.7
which is being refreshed)
org.apache.karaf.shell.ssh/4.0.6 (Wired to
org.apache.karaf.jaas.modules/4.0.6 which is being refreshed)
org.apache.cxf.services.sts.core/3.1.7 (Bundle will be uninstalled)
{code}
Even the org.apache.cxf.interceptor.security package is optional in the
Import-Package, and by default the DigestPasswordLoginModule is not activated,
the org.apache.karaf.jaas.modules still got refreshed and then break the ssh
connection.
With the older Karaf 4.0.5/CXF 3.1.5, there is no this kind of problem.
{code}
Uninstalling bundles:
org.apache.cxf.services.sts.core/3.1.5
Refreshing bundles:
org.apache.cxf.cxf-core/3.1.5 (Wired to
org.apache.cxf.services.sts.core/3.1.5 which is being refreshed)
org.apache.cxf.services.sts.core/3.1.5 (Bundle will be uninstalled)
{code}
> Add DigestPasswordLoginModule so PasswordDigest can work with Karaf JAAS
> realm
> -------------------------------------------------------------------------------
>
> Key: KARAF-4520
> URL: https://issues.apache.org/jira/browse/KARAF-4520
> Project: Karaf
> Issue Type: Improvement
> Reporter: Freeman Fang
> Assignee: Freeman Fang
> Fix For: 4.1.0, 4.0.6
>
>
> So far the assumption with JAAS login modules is that the password is to be
> compared "as is". However per the ws-security spec, the PasswordDigest for
> UsernameToken is "the concatenation of the nonce plus the creation time plus
> the password. The nonce is 16 bytes long and is passed along as a base64
> encoded value. The way this works is that the client creates the password
> hash using all of this information plus the password". So the PasswordDigest
> would change per each invocation, so we can't simply store the passwords in a
> digest form in the properties file.
> The way to make it work, I think we need a DigestPasswordLoginModule which
> use a customized checkPassword method where can compare the stored password
> and the digest password from PasswordCallback (we may need take a close look
> how this part implemented in WSS4J for digest password comparing)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
