[JBoss JIRA] (WFCORE-2521) TLS between domain and host controllers does not work
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2521?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2521:
-------------------------------
Fix Version/s: 3.0.0.Beta16
(was: 3.0.0.Beta15)
> TLS between domain and host controllers does not work
> -----------------------------------------------------
>
> Key: WFCORE-2521
> URL: https://issues.jboss.org/browse/WFCORE-2521
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: domain-management, domain-mode, eap71_alpha, regression, ssl
> Fix For: 3.0.0.Beta16
>
>
> This is regression against EAP 7.0 . Customers relying on this feature won't be able to migrate to EAP 7.1.
> Working configuration of TLS between domain and host controller from EAP 7.0 (legacy) does not work on EAP 7.1 anymore.
> In server log there is this error:
> {code:title=server.log}
> [Host Controller] Caused by: java.io.IOException: Client starting STARTTLS but channel doesn't support SSL
> [Host Controller] at org.jboss.remoting3.remote.ClientConnectionOpenListener$StartTls.handleEvent(ClientConnectionOpenListener.java:527)
> [Host Controller] at org.jboss.remoting3.remote.ClientConnectionOpenListener$StartTls.handleEvent(ClientConnectionOpenListener.java:477)
> [Host Controller] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> [Host Controller] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> [Host Controller] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> [Host Controller] at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> [Host Controller] at ...asynchronous invocation...(Unknown Source)
> [Host Controller] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:466)
> [Host Controller] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:437)
> [Host Controller] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:430)
> [Host Controller] at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:163)
> [Host Controller] at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119)
> [Host Controller] ... 9 more
> {code}
> See attached server.log for context log.
> Tests in wildfly-core covering this scenario are currently ignored:
> * SSLMasterSlaveOneWayTestCase is ignored by WFCORE-1978
> * SSLMasterSlaveTwoWayTestCase is ignored by WFCORE-2068
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2655) Add option to wrap the GSSCredential in kerberos security factory
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2655?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2655:
-------------------------------
Fix Version/s: 3.0.0.Beta16
(was: 3.0.0.Beta15)
> Add option to wrap the GSSCredential in kerberos security factory
> -----------------------------------------------------------------
>
> Key: WFCORE-2655
> URL: https://issues.jboss.org/browse/WFCORE-2655
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 3.0.0.Beta14
> Reporter: Stefan Guilhen
> Assignee: Stefan Guilhen
> Fix For: 3.0.0.Beta16
>
>
> The legacy KerberosLoginModule has an option called wrapGssCredential that tells the code building the GSSCredential that it should wrap the constructed credential to prevent improper credential disposal by some DB drivers. It essentially delegates every method to the wrapped GSSCredential but makes dispose() a no-op.
> The kerberos security factory in the Elytron subsystem doesn't offer an option to wrap the credential and it creates a backwards compatibility problem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2666) Elytron ApplicationDomain allows anonymous authentication
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2666?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2666:
-------------------------------
Fix Version/s: 3.0.0.Beta16
(was: 3.0.0.Beta15)
> Elytron ApplicationDomain allows anonymous authentication
> ---------------------------------------------------------
>
> Key: WFCORE-2666
> URL: https://issues.jboss.org/browse/WFCORE-2666
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta14
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: eap7.1-rfe-failure, eap71_beta_candidate
> Fix For: 3.0.0.Beta16
>
>
> New default Elytron {{ApplicationDomain}} security domain allows anonymous authentication but PicketBox's default security {{other}} does not. As it's expected that {{ApplicationDomain}} should be equivalent to {{other}} security domain this should behave the same.
> _Customer impact:_ If customer switches from PicketBox to Elytron default security domain then it brings risk of unintentional permission of anonymous authentication. This would be security hole.
> This is ongoing discussion from JBEAP-9117 where this is discussed for messaging subsystem however this decision affects other subsystems and goes beyond messaging.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months