[JBoss JIRA] (WFLY-3657) JAXWS handlers do not support injection
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-3657?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on WFLY-3657:
---------------------------------------
OK, I've reproduced your issue, will investigate on tomorrow and let you know.
As for the JBWS2634TestCase, see http://anonsvn.jboss.org/repos/jbossws/stack/cxf/trunk/modules/testsuite/...
> JAXWS handlers do not support injection
> ---------------------------------------
>
> Key: WFLY-3657
> URL: https://issues.jboss.org/browse/WFLY-3657
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Affects Versions: 8.1.0.Final
> Environment: Ubuntu 12.04
> JDK 1.8.0_11
> Reporter: Thomas Kriechbaum
> Assignee: Alessio Soldano
> Attachments: jaxws-handler-war.zip, wildfly-test-soapui-project.xml
>
>
> According to the JavaEE spec JAXWS-handlers should support injection (@Inject, @EJB), @PostConstruct and @PreDestroy.
> In my test case (top-down approach, handler class is defined within *_handler.xml) @PostCunstruct works, but managed beans (CDI, EJB) are not injected via @Inject or @EJB.
> Possible workaround for EJBs: manual JNDI-lookup within @PostConstruct method. For CDI-managed beans you have to lookup the BeanManager and load the desired bean yourself.
> It seems, that this issue should have been addressed by WFLY-2362. But it is still does not work.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 12 months
[JBoss JIRA] (WFLY-3659) wildfly 8 digest login-config throws javax.security.auth.callback.UnsupportedCallbackException
by Bradley Snyder (JIRA)
[ https://issues.jboss.org/browse/WFLY-3659?page=com.atlassian.jira.plugin.... ]
Bradley Snyder commented on WFLY-3659:
--------------------------------------
Referencing this thread: https://community.jboss.org/thread/242747
It appears that the presence of JBossCallbackHandler.handle in the stack trace is the problem. When using Digest and org.jboss.security.auth.callback.RFC2617Digest DigestCallback, the DigestCallbackHandler should be used. But there doesn't seem to be anyway to get that referenced. The older jboss-as-security_1_0.xsd as a "default-callback-handler-class-name" attribute for the <security-management> element of the security subsystem, but that appears to be deprecated. And even if it wasn't, that would enforce DigestCallbackHandler for all <login-module>s, even non-Digest ones.
> wildfly 8 digest login-config throws javax.security.auth.callback.UnsupportedCallbackException
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-3659
> URL: https://issues.jboss.org/browse/WFLY-3659
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security, Web (Undertow)
> Affects Versions: 8.1.0.Final
> Reporter: Joseph Hwang
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.Beta1
>
>
> Password encryption in database login module with wildfly digest login config throws javax.security.auth.callback.UnsupportedCallbackException. These are sources.
> == web.xml
> <security-role>
> <role-name>administrator</role-name>
> </security-role>
> <login-config>
> <auth-method>DIGEST</auth-method>
> <realm-name>WildFly8DigestRealm</realm-name>
> </login-config>
> == jboss-web.xml
> <jboss-web>
> <security-domain>java:/jaas/my_secure_domain</security-domain>
> </jboss-web>
> == standalone.xml
> <security-domain name="my_secure_domain" cache-type="default">
> <authentication>
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/MySqlDS"/>
> <module-option name="principalsQuery" value="select password from credential where uid=?"/>
> <module-option name="rolesQuery" value="select urole, 'Roles' from credential where uid=?"/>
> <module-option name="hashAlgorithm" value="MD5"/>
> <module-option name="hashEncoding" value="RFC2617"/>
> <module-option name="hashUserPassword" value="false"/>
> <module-option name="hashStorePassword" value="true"/>
> <module-option name="passwordIsA1Hash" value="true"/>
> <module-option name="digestCallback" value="org.jboss.security.auth.callback.DigestCallbackHandler"/>
> <module-option name="storeDigestCallback" value="org.jboss.security.auth.callback.RFC2617Digest"/>
> </login-module>
> </authentication>
> </security-domain>
> Password is encrypted with below codes
> == EncryptPassword.java
> package com.aaa.encrypt;
> import org.jboss.crypto.CryptoUtil;
> public class EncryptPassword {
> public static void main(String[] args) {
> // TODO Auto-generated method stub
> String userName="admin";
> String realmName="WildFly8DigestRealm";
> String password="passwd123";
> String clearTextPassword=userName+":"+realmName+":"+password;
> String hashedPassword=CryptoUtil.createPasswordHash("MD5", "RFC2617", null, null, clearTextPassword);
> System.out.println("clearTextPassword: "+clearTextPassword);
> System.out.println("hashedPassword: "+hashedPassword);
> }
> }
> But login failed! The log shows the folowing exceptions :
> 2014-07-18 21:37:45,246 TRACE [org.jboss.security] (default task-3) PBOX000236: Begin initialize method
> 2014-07-18 21:37:45,246 DEBUG [org.jboss.security] (default task-3) PBOX000281: Password hashing activated, algorithm: MD5, encoding: RFC2617, charset: null, callback: org.jboss.security.auth.callback.DigestCallbackHandler, storeCallBack: org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000262: Module options [dsJndiName: java:jboss/datasources/MySqlDS, principalsQuery: select password from credential where uid=?, rolesQuery: select urole, 'Roles' from credential where uid=?, suspendResume: true]
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000240: Begin login method
> 2014-07-18 21:37:45,249 TRACE [org.jboss.security] (default task-3) PBOX000263: Executing query select password from credential where uid=? with username admin
> 2014-07-18 21:37:45,251 TRACE [org.jboss.security] (default task-3) PBOX000284: Created DigestCallback org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,252 TRACE [org.jboss.security] (default task-3) PBOX000244: Begin abort method
> 2014-07-18 21:37:45,252 DEBUG [org.jboss.security] (default task-3) PBOX000206: Login failure: javax.security.auth.login.LoginException: PBOX000055: Failed to invoke CallbackHandler
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:444) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:280) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_60]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_60]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) [rt.jar:1.7.0_60]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.login(LoginContext.java:595) [rt.jar:1.7.0_60]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:77)
> at io.undertow.security.impl.DigestAuthenticationMechanism.handleDigestHeader(DigestAuthenticationMechanism.java:265) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:149) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
> Caused by: javax.security.auth.callback.UnsupportedCallbackException
> at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:947) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:944) [rt.jar:1.7.0_60]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:943) [rt.jar:1.7.0_60]
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:434) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> ... 49 more
> This cofiguration worked well in JBoss AS 7.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 12 months
[JBoss JIRA] (WFLY-3657) JAXWS handlers do not support injection
by Thomas Kriechbaum (JIRA)
[ https://issues.jboss.org/browse/WFLY-3657?page=com.atlassian.jira.plugin.... ]
Thomas Kriechbaum commented on WFLY-3657:
-----------------------------------------
could you be so kind and give me a link to JBWS2634TestCase.java
Thanks,
Thomas
> JAXWS handlers do not support injection
> ---------------------------------------
>
> Key: WFLY-3657
> URL: https://issues.jboss.org/browse/WFLY-3657
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Affects Versions: 8.1.0.Final
> Environment: Ubuntu 12.04
> JDK 1.8.0_11
> Reporter: Thomas Kriechbaum
> Assignee: Alessio Soldano
> Attachments: jaxws-handler-war.zip, wildfly-test-soapui-project.xml
>
>
> According to the JavaEE spec JAXWS-handlers should support injection (@Inject, @EJB), @PostConstruct and @PreDestroy.
> In my test case (top-down approach, handler class is defined within *_handler.xml) @PostCunstruct works, but managed beans (CDI, EJB) are not injected via @Inject or @EJB.
> Possible workaround for EJBs: manual JNDI-lookup within @PostConstruct method. For CDI-managed beans you have to lookup the BeanManager and load the desired bean yourself.
> It seems, that this issue should have been addressed by WFLY-2362. But it is still does not work.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 12 months
[JBoss JIRA] (WFLY-3657) JAXWS handlers do not support injection
by Thomas Kriechbaum (JIRA)
[ https://issues.jboss.org/browse/WFLY-3657?page=com.atlassian.jira.plugin.... ]
Thomas Kriechbaum updated WFLY-3657:
------------------------------------
Attachment: jaxws-handler-war.zip
wildfly-test-soapui-project.xml
jaxws-handler-war.zip
maven-based project containing a webservice with an associated jaxws-handler.
wildfly-test-soap-ui-project.xml
contains a test-message
> JAXWS handlers do not support injection
> ---------------------------------------
>
> Key: WFLY-3657
> URL: https://issues.jboss.org/browse/WFLY-3657
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Affects Versions: 8.1.0.Final
> Environment: Ubuntu 12.04
> JDK 1.8.0_11
> Reporter: Thomas Kriechbaum
> Assignee: Alessio Soldano
> Attachments: jaxws-handler-war.zip, wildfly-test-soapui-project.xml
>
>
> According to the JavaEE spec JAXWS-handlers should support injection (@Inject, @EJB), @PostConstruct and @PreDestroy.
> In my test case (top-down approach, handler class is defined within *_handler.xml) @PostCunstruct works, but managed beans (CDI, EJB) are not injected via @Inject or @EJB.
> Possible workaround for EJBs: manual JNDI-lookup within @PostConstruct method. For CDI-managed beans you have to lookup the BeanManager and load the desired bean yourself.
> It seems, that this issue should have been addressed by WFLY-2362. But it is still does not work.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 12 months
[JBoss JIRA] (ELY-26) SecurityRealm API - Take 2
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-26:
-----------------------------------
Summary: SecurityRealm API - Take 2
Key: ELY-26
URL: https://issues.jboss.org/browse/ELY-26
Project: WildFly Elytron
Issue Type: Task
Security Level: Public (Everyone can see)
Components: API / SPI, Realms
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.0.0.Beta1
The security realm API currently is stateless, each call is independent of all of the others - whilst we may want to make assumptions about the order of the calls this can not be guaranteed.
One issue identified is splitting up the text manipulation based name mappings from the actual lookup if applicable and conversion to a Principal.
Another thought raised is to add support for a RealmIdentity method specific to the identity could be moved to this identity.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 12 months
[JBoss JIRA] (WFLY-3253) CXF should not be installing BouncyCastle
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-3253?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on WFLY-3253:
---------------------------------------
Unfortunately, having Apache Santuario and Apache WSS4J change to avoid relying on the global security providers is not an option. It is however possible to prevent WSS4J from installing BC at all, which leaves us with the need for always making available the algorithms currently provided by BC. This needs to be the default situation, as explained above. Hence the idea of a custom provider proxying other providers (BC in this case) on a classloading base could be a valid solution.
> CXF should not be installing BouncyCastle
> -----------------------------------------
>
> Key: WFLY-3253
> URL: https://issues.jboss.org/browse/WFLY-3253
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Reporter: David Lloyd
> Assignee: Alessio Soldano
> Priority: Critical
> Fix For: 9.0.0.Beta1
>
>
> CXF installs a BouncyCastle provider globally into the security providers list. This is causes performance and other problems when this provider gets chosen for whatever reason to be the system crypto provider for e.g. TLS.
> The list of globally installed security providers should be a user concern only. If CXF requires a specific provider for a specific purpose, it should be selecting that provider when constructing the crytpo API object, though generally this is to be discouraged.
> Ultimately we want to introduce a configuration in the app server that allows the list of security providers to be specified in some way, without interference from any frameworks that we happen to have installed.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 12 months
[JBoss JIRA] (WFLY-2738) Deprecated resource is present in r-r-d of /subsystem=security/security-domain=*
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2738?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-2738:
----------------------------------------
>From a chat:
ehsavoie: bstansberry: to be franck there was a "bug" in 2738 depending on the interpretation as we would show the alias descendant as undefined insted of simply hidding it
bstansberry: yep
A possible other solution to this is to simply fix that bug; i.e. get rid of the "*" => undefined bit and reduce it to "model-description" => {}. I'm not sure how helpful that would be to the console guys, but if it's helpful or the full change I outlined above is just too much, for sure let's do that little bit.
> Deprecated resource is present in r-r-d of /subsystem=security/security-domain=*
> --------------------------------------------------------------------------------
>
> Key: WFLY-2738
> URL: https://issues.jboss.org/browse/WFLY-2738
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.CR1
> Reporter: Harald Pehl
> Assignee: Emmanuel Hugonnet
> Priority: Minor
> Fix For: 9.0.0.CR1
>
>
> When executing
> {code}
> /subsystem=security/security-domain=*:read-resource-description(recursive-depth=2)
> {code}
> the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}:
> {code}
> ...
> "acl" => {
> "description" => "Access control list configuration. Configures a list of ACL modules to be used.",
> "model-description" => {"classic" => {
> "description" => "Access control list configuration. Configures a list of ACL modules to be used.",
> ...
> "operations" => undefined,
> "children" => {
> "acl-module" => {
> "description" => "ACL module",
> "model-description" => {"*" => {
> "description" => "List of authentication modules",
> ...
> "operations" => undefined,
> "children" => {}
> }}
> },
> "login-module" => {
> "description" => "Login module",
> "model-description" => {"*" => undefined}
> }
> }
> }}
> },
> ...
> {code}
> However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=true}}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 12 months