[JBoss JIRA] (WFLY-8601) FileKeystore is hard to use with non-file-based keystores
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-8601?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-8601:
--------------------------------------
Assignee: (was: Darran Lofthouse)
> FileKeystore is hard to use with non-file-based keystores
> ---------------------------------------------------------
>
> Key: WFLY-8601
> URL: https://issues.jboss.org/browse/WFLY-8601
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Pazdziora
>
> We are implementing JCA KeyStore provider to get certificates and keys via external process over the network:
> https://github.com/latchset/custodia-jca-provider
> However, code in https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... makes use of such code hard.
> It seems that FileKeystore has two modes of operation -- either alias is specified and then the KeyStore is treated as file (isKeyStore = true) which has to exist and it has to be able to list aliases, or the file is not required to exist (isKeyStore = false) but then alias cannot be specified (and if it is specified as alias attribute to <keystore> element, it is ignored).
> In case we'd like to be able to use our provider without additional configuration in java.security, we'd like to be able to specify alias to retrieve specified entry, especially since getting the list of aliases might be either slow (for large sets) or not possible. For that however, we need to go the isKeyStore = true route with path specified and file existing. Alas, when we try
> <ssl>
> <keystore provider="custodia-cli" path="/dev/null" alias="wildfly/server-ssl" keystore-password="thepassword" />
> </ssl>
> then due to the extra check in WildFly's code, startup fails with
> Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYDM0083: The KeyStore /dev/null does not contain any keys.
> at org.jboss.as.domain.management.security.FileKeystore.assertContainsKey(FileKeystore.java:169)
> at org.jboss.as.domain.management.security.FileKeystore.load(FileKeystore.java:120)
> at org.jboss.as.domain.management.security.FileKeyManagerService.loadKeyStore(FileKeyManagerService.java:189)
> Please consider removing the
> if (isKeyStore) {
> assertContainsKey(loadedKeystore);
> }
> code from https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... since existence of the keystore file does not guarantee that the keys will be stored in it and that the provider will be able to loop through them. The file might be just /dev/null or some config file of the provider.
> Ideally though, it should be possible to specify alias even for keystore which has no path specified.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-3046) FileKeystore is hard to use with non-file-based keystores
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3046?page=com.atlassian.jira.plugi... ]
Darran Lofthouse moved WFLY-8601 to WFCORE-3046:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-3046 (was: WFLY-8601)
Component/s: Security
(was: Security)
Affects Version/s: (was: 10.1.0.Final)
> FileKeystore is hard to use with non-file-based keystores
> ---------------------------------------------------------
>
> Key: WFCORE-3046
> URL: https://issues.jboss.org/browse/WFCORE-3046
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jan Pazdziora
>
> We are implementing JCA KeyStore provider to get certificates and keys via external process over the network:
> https://github.com/latchset/custodia-jca-provider
> However, code in https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... makes use of such code hard.
> It seems that FileKeystore has two modes of operation -- either alias is specified and then the KeyStore is treated as file (isKeyStore = true) which has to exist and it has to be able to list aliases, or the file is not required to exist (isKeyStore = false) but then alias cannot be specified (and if it is specified as alias attribute to <keystore> element, it is ignored).
> In case we'd like to be able to use our provider without additional configuration in java.security, we'd like to be able to specify alias to retrieve specified entry, especially since getting the list of aliases might be either slow (for large sets) or not possible. For that however, we need to go the isKeyStore = true route with path specified and file existing. Alas, when we try
> <ssl>
> <keystore provider="custodia-cli" path="/dev/null" alias="wildfly/server-ssl" keystore-password="thepassword" />
> </ssl>
> then due to the extra check in WildFly's code, startup fails with
> Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYDM0083: The KeyStore /dev/null does not contain any keys.
> at org.jboss.as.domain.management.security.FileKeystore.assertContainsKey(FileKeystore.java:169)
> at org.jboss.as.domain.management.security.FileKeystore.load(FileKeystore.java:120)
> at org.jboss.as.domain.management.security.FileKeyManagerService.loadKeyStore(FileKeyManagerService.java:189)
> Please consider removing the
> if (isKeyStore) {
> assertContainsKey(loadedKeystore);
> }
> code from https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... since existence of the keystore file does not guarantee that the keys will be stored in it and that the provider will be able to loop through them. The file might be just /dev/null or some config file of the provider.
> Ideally though, it should be possible to specify alias even for keystore which has no path specified.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-3045) Elytron - unable to use OTP SASL mechanism
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3045?page=com.atlassian.jira.plugi... ]
Darran Lofthouse moved WFLY-8667 to WFCORE-3045:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-3045 (was: WFLY-8667)
Component/s: Security
(was: Security)
> Elytron - unable to use OTP SASL mechanism
> ------------------------------------------
>
> Key: WFCORE-3045
> URL: https://issues.jboss.org/browse/WFCORE-3045
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: eap7.1-rfe-failure
>
> I'm not able to use the new OTP SASL mechanism in WildFly (introduced as part of EAP7-530).
> It seems the only security-realm which has subsystem support for OTP is the {{ldap-realm}} now. Nevertheless the name filtering in {{AbstractMechanismAuthenticationFactory.getMechanismNames()}} doesn't return OTP as supported in ldap-realm. Neither the {{PasswordGuessEvidence}} nor {{PasswordCredential}} checked in the method seems to be supported.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8750) RBAC, Security subsystem contains attributes with capabilities which don't set access-constraint.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-8750?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-8750.
------------------------------------
Fix Version/s: 11.0.0.Beta1
Resolution: Done
> RBAC, Security subsystem contains attributes with capabilities which don't set access-constraint.
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-8750
> URL: https://issues.jboss.org/browse/WFLY-8750
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 11.0.0.Beta1
>
>
> This is potentially security vulnerability therefore it is BLOCKER.
> Security subsystem contains attributes with capabilities which don't set access-constraint.
> All of them have Elytron compatibility capability and I expect there some access constraint too.
> *How to reproduce:*
> {code}
> /subsystem=security:read-resource-description(recursive=true)
> {code}
> There are some places where missing access constraints.
> elytron-key-store with *org.wildfly.security.key-store* capability.
> elytron-realm with *org.wildfly.security.security-realm* capability.
> elytron-trust-manager with *org.wildfly.security.trust-managers* capability.
> elytron-key-manager with *org.wildfly.security.key-managers* capability.
> elytron-trust-store with *org.wildfly.security.key-store* capability.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8749) RBAC, There are missing access-constraint for attributes which referencing elytron capabilities.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-8749?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-8749.
------------------------------------
Fix Version/s: 11.0.0.Beta1
Assignee: Stefan Guilhen
Resolution: Done
> RBAC, There are missing access-constraint for attributes which referencing elytron capabilities.
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-8749
> URL: https://issues.jboss.org/browse/WFLY-8749
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Stefan Guilhen
> Priority: Blocker
> Fix For: 11.0.0.Beta1
>
>
> This is potentially security vulnerability therefore it is BLOCKER.
> According to RFE EAP7-548 there must be set access-constraint where are referenced elytron capabilities.
> I found 6 places where is access-constraint missing.
> {code}
> /subsystem=undertow:read-resource-description(recursive=true)
> {code}
> There is *http-invoker*, attr *http-authentication-factory* with *org.wildfly.security.http-authentication-factory* capability.
> {code}
> /subsystem=datasources:read-resource-description(recursive=true)
> {code}
> There is *xa-data-source*, attr *recovery-authentication-context* with *org.wildfly.security.authentication-context* capability.
> {code}
> /subsystem=ejb3:read-resource-description(recursive=true)
> {code}
> There is *identity*, attr *outflow-security-domains* with *org.wildfly.security.security-domain* capability.
> {code}
> /core-service=management/management-interface=http-interface:read-resource-description(recursive=true)
> {code}
> There is *sasl-authentication-factory* with *org.wildfly.security.sasl-authentication-factory* capability.
> {code}
> /deployment=test:read-resource-description(recursive=true)
> {code}
> There is *xa-data-source*, attr *recovery-authentication-context* with *org.wildfly.security.authentication-context* capability
> and *there is same problem in subdeployment resource too*.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-3044) Remoting connection sharing causes authentication failures - DIGEST SASL mechanism
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3044?page=com.atlassian.jira.plugi... ]
Darran Lofthouse moved WFLY-8799 to WFCORE-3044:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-3044 (was: WFLY-8799)
Component/s: Remoting
Security
(was: Remoting)
(was: Security)
> Remoting connection sharing causes authentication failures - DIGEST SASL mechanism
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-3044
> URL: https://issues.jboss.org/browse/WFCORE-3044
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting, Security
> Reporter: Josef Cacek
> Assignee: David Lloyd
> Priority: Blocker
> Fix For: 3.0.0.Beta29
>
>
> Server rejects DIGEST SASL authentication in some cases when an existing remoting connection is reused. It seems the protocol name is not updated or matched correctly. The root cause of the problem is moreover hidden due to JBEAP-10953.
> Clients just get:
> {noformat}
> Caused by: org.wildfly.security.auth.AuthenticationException: JBREM000304: Server rejected authentication
> at org.jboss.remoting3.ConnectionPeerIdentityContext.doAuthenticate(ConnectionPeerIdentityContext.java:340)
> at org.jboss.remoting3.ConnectionPeerIdentityContext.authenticate(ConnectionPeerIdentityContext.java:178)
> at org.jboss.remoting3.EndpointImpl$3.handleDone(EndpointImpl.java:478)
> at org.jboss.remoting3.EndpointImpl$3.handleDone(EndpointImpl.java:467)
> ...
> {noformat}
> The hidden exception stack trace is:
> {noformat}
> javax.security.sasl.SaslException: ELY05088: [DIGEST-MD5] digest-uri "remote+http/doma" not accepted
> at org.wildfly.security.sasl.digest.DigestSaslServer.validateDigestResponse(DigestSaslServer.java:239)
> at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateMessage(DigestSaslServer.java:355)
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180)
> at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateResponse(DigestSaslServer.java:328)
> at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
> at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106)
> at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:57)
> at org.jboss.remoting3.ConnectionImpl.lambda$receiveAuthResponse$3(ConnectionImpl.java:273)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:897)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> We hit this problem as an intermittent failure in the AS testsuite.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-3044) Remoting connection sharing causes authentication failures - DIGEST SASL mechanism
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3044?page=com.atlassian.jira.plugi... ]
Darran Lofthouse resolved WFCORE-3044.
--------------------------------------
Fix Version/s: 3.0.0.Beta29
Resolution: Done
> Remoting connection sharing causes authentication failures - DIGEST SASL mechanism
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-3044
> URL: https://issues.jboss.org/browse/WFCORE-3044
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting, Security
> Reporter: Josef Cacek
> Assignee: David Lloyd
> Priority: Blocker
> Fix For: 3.0.0.Beta29
>
>
> Server rejects DIGEST SASL authentication in some cases when an existing remoting connection is reused. It seems the protocol name is not updated or matched correctly. The root cause of the problem is moreover hidden due to JBEAP-10953.
> Clients just get:
> {noformat}
> Caused by: org.wildfly.security.auth.AuthenticationException: JBREM000304: Server rejected authentication
> at org.jboss.remoting3.ConnectionPeerIdentityContext.doAuthenticate(ConnectionPeerIdentityContext.java:340)
> at org.jboss.remoting3.ConnectionPeerIdentityContext.authenticate(ConnectionPeerIdentityContext.java:178)
> at org.jboss.remoting3.EndpointImpl$3.handleDone(EndpointImpl.java:478)
> at org.jboss.remoting3.EndpointImpl$3.handleDone(EndpointImpl.java:467)
> ...
> {noformat}
> The hidden exception stack trace is:
> {noformat}
> javax.security.sasl.SaslException: ELY05088: [DIGEST-MD5] digest-uri "remote+http/doma" not accepted
> at org.wildfly.security.sasl.digest.DigestSaslServer.validateDigestResponse(DigestSaslServer.java:239)
> at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateMessage(DigestSaslServer.java:355)
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180)
> at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateResponse(DigestSaslServer.java:328)
> at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
> at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106)
> at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:57)
> at org.jboss.remoting3.ConnectionImpl.lambda$receiveAuthResponse$3(ConnectionImpl.java:273)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:897)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> We hit this problem as an intermittent failure in the AS testsuite.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-3043) When is operation add-alias run more times for same alias name then is displayed \" instead of only " in failure description.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3043?page=com.atlassian.jira.plugi... ]
Darran Lofthouse moved WFLY-8856 to WFCORE-3043:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-3043 (was: WFLY-8856)
Component/s: Security
(was: Security)
> When is operation add-alias run more times for same alias name then is displayed \" instead of only " in failure description.
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3043
> URL: https://issues.jboss.org/browse/WFCORE-3043
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
>
> When is operation add-alias run more times for same alias name then is displayed \" instead of only " in failure description.
> There is expected quotation without backslash in failure description.
> *How to reproduce*
> *create credential store*
> {code}
> /subsystem=elytron/credential-store=cs001:add(create=true, credential-reference={clear-text=pass123},location=cs001.jceks)
> {code}
> *Try to add-alias twice and for second run you get failure description.*
> {code}
> /subsystem=elytron/credential-store=cs001:add-alias(alias=alias001, secret-value="secret_value")
> /subsystem=elytron/credential-store=cs001:add-alias(alias=alias001, secret-value="secret_value")
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "WFLYELY00913: Credential alias \"alias001\" of credential type \"org.wildfly.security.credential.PasswordCredential\" already exists in the store",
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8961) Elytron in JMS: Unable to use authenticate with JBOSS-LOCAL-USER
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-8961?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-8961:
-----------------------------------
Issue Type: Feature Request (was: Bug)
> Elytron in JMS: Unable to use authenticate with JBOSS-LOCAL-USER
> ----------------------------------------------------------------
>
> Key: WFLY-8961
> URL: https://issues.jboss.org/browse/WFLY-8961
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS, Security
> Reporter: Josef Cacek
> Assignee: Jeff Mesnil
> Priority: Critical
> Labels: eap7.1.0-to-prd
>
> I'm not able to authenticate to JMS when using JBOSS-LOCAL-USER SASL mechanism. {{ConnectionFactory.createContext()}} call and the client call fails with:
> {noformat}
> javax.jms.JMSSecurityRuntimeException: AMQ119031: Unable to validate user
> {noformat}
> This issue is similar to JBEAP-10527, but for JBOSS-LOCAL-USER mechanism (compared to DIGEST-MD5 for instance) we don't have a username or password. This problem can be in other SASL mechanisms too (e.g. EXTERNAL - where we authenticate a user with client certificate).
> Code used for testing:
> {code:java}
> AuthenticationContext.empty()
> .with(MatchRule.ALL,
> AuthenticationConfiguration.empty().useProvidersFromClassLoader(getClass().getClassLoader())
> .setSaslMechanismSelector(SaslMechanismSelector.fromString("JBOSS-LOCAL-USER")))
> .run(() -> {
> try {
> // ... initialize naming etc. here
> ConnectionFactory connectionFactory = (ConnectionFactory) namingContext
> .lookup("jms/RemoteConnectionFactory");
> JMSContext context = connectionFactory.createContext();
> } catch (NamingException e) {
> // ...
> }
> });
> {code}
> Server log contains:
> {noformat}
> 2017-06-08 15:00:07,076 TRACE [org.wildfly.security] (default I/O-4) Handling MechanismInformationCallback type='SASL' name='JBOSS-LOCAL-USER' host-name='localhost' protocol='remote'
> 2017-06-08 15:00:07,077 TRACE [org.wildfly.security] (default I/O-4) Handling MechanismInformationCallback type='SASL' name='JBOSS-LOCAL-USER' host-name='localhost' protocol='remote'
> 2017-06-08 15:00:07,077 TRACE [org.wildfly.security] (default I/O-4) Created SaslServer [org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1@55b75111] for mechanism [JBOSS-LOCAL-USER]
> 2017-06-08 15:00:07,083 TRACE [org.wildfly.security] (default task-2) Handling NameCallback: authenticationName = $local
> 2017-06-08 15:00:07,083 TRACE [org.wildfly.security] (default task-2) Principal assigning: [$local], pre-realm rewritten: [$local], realm name: [local], post-realm rewritten: [$local], realm rewritten: [$local]
> 2017-06-08 15:00:07,084 TRACE [org.wildfly.security] (default task-2) Role mapping: principal [$local] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [guest]
> 2017-06-08 15:00:07,084 TRACE [org.wildfly.security] (default task-2) Authorizing principal $local.
> 2017-06-08 15:00:07,084 TRACE [org.wildfly.security] (default task-2) Authorizing against the following attributes: [] => []
> 2017-06-08 15:00:07,084 TRACE [org.wildfly.security] (default task-2) Permission mapping: identity [$local] with roles [guest] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-06-08 15:00:07,095 TRACE [org.wildfly.security] (default task-2) Authorization succeed
> 2017-06-08 15:00:07,095 TRACE [org.wildfly.security] (default task-2) RunAs authorization succeed - the same identity
> 2017-06-08 15:00:07,095 TRACE [org.wildfly.security] (default task-2) Handling AuthorizeCallback: authenticationID = $local authorizationID = $local authorized = true
> 2017-06-08 15:00:07,095 TRACE [org.wildfly.security] (default task-2) Handling AuthenticationCompleteCallback: succeed
> 2017-06-08 15:00:07,099 TRACE [org.wildfly.security] (default task-2) Handling SecurityIdentityCallback: identity = SecurityIdentity{principal=$local, securityDomain=org.wildfly.security.auth.server.SecurityDomain@24c5501a, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='local', securityRealm=org.wildfly.security.auth.realm.SimpleMapBackedSecurityRealm@426b003b}, creationTime=2017-06-08T13:00:07.083Z}
> 2017-06-08 15:00:07,142 INFO [org.wildfly.naming] (default task-4) WildFly Naming version 1.0.0.Beta16
> 2017-06-08 15:00:07,908 TRACE [org.wildfly.security] (default I/O-3) Permission mapping: identity [anonymous] with roles [guest] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = false
> 2017-06-08 15:00:07,920 DEBUG [org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl] (default I/O-3) Couldn't find any bindings for address=activemq.notifications on message=ServerMessage[messageID=25,durable=true,userID=null,priority=0, bodySize=512, timestamp=0,expiration=0, durable=true, address=activemq.notifications,properties=TypedProperties[_AMQ_NotifType=SECURITY_AUTHENTICATION_VIOLATION,_AMQ_NotifTimestamp=1496926807920]]@1825253250
> 2017-06-08 15:00:07,920 DEBUG [org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl] (default I/O-3) Message ServerMessage[messageID=25,durable=true,userID=null,priority=0, bodySize=512, timestamp=0,expiration=0, durable=true, address=activemq.notifications,properties=TypedProperties[_AMQ_NotifType=SECURITY_AUTHENTICATION_VIOLATION,_AMQ_NotifTimestamp=1496926807920]]@1825253250 is not going anywhere as it didn't have a binding on address:activemq.notifications
> 2017-06-08 15:00:07,924 ERROR [org.apache.activemq.artemis.core.server] (default I/O-3) AMQ224018: Failed to create session: ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ119031: Unable to validate user]
> at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:144)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1283)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:623)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:379)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:362)
> at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:69)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:443)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:379)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> {noformat}
> [~dlofthouse], [~jmesnil], Is there another way to use these SASL mechanisms (without username and password) to create JMSContext? If not then we should change priority to blocker.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8961) Elytron in JMS: Unable to use authenticate with JBOSS-LOCAL-USER
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-8961?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-8961:
-----------------------------------
Priority: Major (was: Critical)
> Elytron in JMS: Unable to use authenticate with JBOSS-LOCAL-USER
> ----------------------------------------------------------------
>
> Key: WFLY-8961
> URL: https://issues.jboss.org/browse/WFLY-8961
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS, Security
> Reporter: Josef Cacek
> Assignee: Jeff Mesnil
> Labels: eap7.1.0-to-prd
>
> I'm not able to authenticate to JMS when using JBOSS-LOCAL-USER SASL mechanism. {{ConnectionFactory.createContext()}} call and the client call fails with:
> {noformat}
> javax.jms.JMSSecurityRuntimeException: AMQ119031: Unable to validate user
> {noformat}
> This issue is similar to JBEAP-10527, but for JBOSS-LOCAL-USER mechanism (compared to DIGEST-MD5 for instance) we don't have a username or password. This problem can be in other SASL mechanisms too (e.g. EXTERNAL - where we authenticate a user with client certificate).
> Code used for testing:
> {code:java}
> AuthenticationContext.empty()
> .with(MatchRule.ALL,
> AuthenticationConfiguration.empty().useProvidersFromClassLoader(getClass().getClassLoader())
> .setSaslMechanismSelector(SaslMechanismSelector.fromString("JBOSS-LOCAL-USER")))
> .run(() -> {
> try {
> // ... initialize naming etc. here
> ConnectionFactory connectionFactory = (ConnectionFactory) namingContext
> .lookup("jms/RemoteConnectionFactory");
> JMSContext context = connectionFactory.createContext();
> } catch (NamingException e) {
> // ...
> }
> });
> {code}
> Server log contains:
> {noformat}
> 2017-06-08 15:00:07,076 TRACE [org.wildfly.security] (default I/O-4) Handling MechanismInformationCallback type='SASL' name='JBOSS-LOCAL-USER' host-name='localhost' protocol='remote'
> 2017-06-08 15:00:07,077 TRACE [org.wildfly.security] (default I/O-4) Handling MechanismInformationCallback type='SASL' name='JBOSS-LOCAL-USER' host-name='localhost' protocol='remote'
> 2017-06-08 15:00:07,077 TRACE [org.wildfly.security] (default I/O-4) Created SaslServer [org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1@55b75111] for mechanism [JBOSS-LOCAL-USER]
> 2017-06-08 15:00:07,083 TRACE [org.wildfly.security] (default task-2) Handling NameCallback: authenticationName = $local
> 2017-06-08 15:00:07,083 TRACE [org.wildfly.security] (default task-2) Principal assigning: [$local], pre-realm rewritten: [$local], realm name: [local], post-realm rewritten: [$local], realm rewritten: [$local]
> 2017-06-08 15:00:07,084 TRACE [org.wildfly.security] (default task-2) Role mapping: principal [$local] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [guest]
> 2017-06-08 15:00:07,084 TRACE [org.wildfly.security] (default task-2) Authorizing principal $local.
> 2017-06-08 15:00:07,084 TRACE [org.wildfly.security] (default task-2) Authorizing against the following attributes: [] => []
> 2017-06-08 15:00:07,084 TRACE [org.wildfly.security] (default task-2) Permission mapping: identity [$local] with roles [guest] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-06-08 15:00:07,095 TRACE [org.wildfly.security] (default task-2) Authorization succeed
> 2017-06-08 15:00:07,095 TRACE [org.wildfly.security] (default task-2) RunAs authorization succeed - the same identity
> 2017-06-08 15:00:07,095 TRACE [org.wildfly.security] (default task-2) Handling AuthorizeCallback: authenticationID = $local authorizationID = $local authorized = true
> 2017-06-08 15:00:07,095 TRACE [org.wildfly.security] (default task-2) Handling AuthenticationCompleteCallback: succeed
> 2017-06-08 15:00:07,099 TRACE [org.wildfly.security] (default task-2) Handling SecurityIdentityCallback: identity = SecurityIdentity{principal=$local, securityDomain=org.wildfly.security.auth.server.SecurityDomain@24c5501a, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='local', securityRealm=org.wildfly.security.auth.realm.SimpleMapBackedSecurityRealm@426b003b}, creationTime=2017-06-08T13:00:07.083Z}
> 2017-06-08 15:00:07,142 INFO [org.wildfly.naming] (default task-4) WildFly Naming version 1.0.0.Beta16
> 2017-06-08 15:00:07,908 TRACE [org.wildfly.security] (default I/O-3) Permission mapping: identity [anonymous] with roles [guest] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = false
> 2017-06-08 15:00:07,920 DEBUG [org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl] (default I/O-3) Couldn't find any bindings for address=activemq.notifications on message=ServerMessage[messageID=25,durable=true,userID=null,priority=0, bodySize=512, timestamp=0,expiration=0, durable=true, address=activemq.notifications,properties=TypedProperties[_AMQ_NotifType=SECURITY_AUTHENTICATION_VIOLATION,_AMQ_NotifTimestamp=1496926807920]]@1825253250
> 2017-06-08 15:00:07,920 DEBUG [org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl] (default I/O-3) Message ServerMessage[messageID=25,durable=true,userID=null,priority=0, bodySize=512, timestamp=0,expiration=0, durable=true, address=activemq.notifications,properties=TypedProperties[_AMQ_NotifType=SECURITY_AUTHENTICATION_VIOLATION,_AMQ_NotifTimestamp=1496926807920]]@1825253250 is not going anywhere as it didn't have a binding on address:activemq.notifications
> 2017-06-08 15:00:07,924 ERROR [org.apache.activemq.artemis.core.server] (default I/O-3) AMQ224018: Failed to create session: ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ119031: Unable to validate user]
> at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:144)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1283)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:623)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:379)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:362)
> at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:69)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:443)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:379)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> {noformat}
> [~dlofthouse], [~jmesnil], Is there another way to use these SASL mechanisms (without username and password) to create JMSContext? If not then we should change priority to blocker.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months