[JBoss JIRA] (ELY-375) Server-side channel binding can cause mismatches
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-375?page=com.atlassian.jira.plugin.sy... ]
David Lloyd updated ELY-375:
----------------------------
Description:
At present, the client and the server both locally query their connection situation to determine whether channel binding aware mechanisms should be made available for authentication. This is done by handling a {{ChannelBindingCallback}} and letting the callback handler determine what type of channel binding should be used, and what the data is.
However, this strategy fails if the client and server choose a different channel binding type, which is very likely to happen if at any point JSSE begins support for acquisition of the tls-unique channel binding data. A newer JDK would have tls-unique data, but an older JDK might only have tls-server-end-point available, resulting in a channel-binding-mismatch type error.
SCRAM allows the client to specify one channel binding type. So if the client supports multiple types, it has to guess at the type most likely to be supported by the server.
SCRAM allows the server to read the client's channel binding type. Ideally, the server would then select the matching channel binding type if it is available, instead of querying for it ahead of time.
So I propose the following:
# On the SCRAM client, continue to use the ChannelBindingCallback to choose the binding type and data.
# Introduce a callback type which allows a mechanism participant to provide a list of available channel binding types.
# On the SCRAM server, instead of using ChannelBindingCallback to select a binding type *and* acquire the binding data, use this channel binding types callback to acquire the set of available channel bindings within the server factory.
# On the SCRAM server, validate the client's selected binding type against the set of available channel bindings.
# Change the ChannelBindingCallback contract, so that if a binding type name is already provided, the corresponding binding data should be provided (or an exception thrown). If no channel binding type name is given, then the callback continues to function as it does today, where a type is chosen and provided along with its data.
# On the SCRAM server, use the modified ChannelBindingCallback contract to acquire the binding data for a pre-selected channel binding type.
was:
At present, the client and the server both locally query their connection situation to determine whether channel binding aware mechanisms should be made available for authentication. This is done by handling a {{ChannelBindingCallback}} and letting the callback handler determine what type of channel binding should be used, and what the data is.
However, this strategy fails if the client and server choose a different channel binding type, which is very likely to happen if at any point JSSE begins support for acquisition of the tls-unique channel binding data. A newer JDK would have tls-unique data, but an older JDK might only have tls-server-end-point available, resulting in a channel-binding-mismatch type error.
SCRAM allows the client to specify one channel binding type. So if the client supports multiple types, it has to guess at the type most likely to be supported by the server.
SCRAM allows the server to read the client's channel binding type. Ideally, the server would then select the matching channel binding type if it is available, instead of querying for it ahead of time.
So I propose the following:
# On the SCRAM client, continue to use the ChannelBindingCallback to choose the binding type and data.
# Introduce a callback type which allows a mechanism participant to provide a list of available channel binding types.
# On the SCRAM server, use the ChannelBindingCallback to acquire the binding data for the already-selected channel binding type.
#
#
> Server-side channel binding can cause mismatches
> ------------------------------------------------
>
> Key: ELY-375
> URL: https://issues.jboss.org/browse/ELY-375
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms, Callbacks
> Reporter: David Lloyd
> Fix For: 1.1.0.Final
>
>
> At present, the client and the server both locally query their connection situation to determine whether channel binding aware mechanisms should be made available for authentication. This is done by handling a {{ChannelBindingCallback}} and letting the callback handler determine what type of channel binding should be used, and what the data is.
> However, this strategy fails if the client and server choose a different channel binding type, which is very likely to happen if at any point JSSE begins support for acquisition of the tls-unique channel binding data. A newer JDK would have tls-unique data, but an older JDK might only have tls-server-end-point available, resulting in a channel-binding-mismatch type error.
> SCRAM allows the client to specify one channel binding type. So if the client supports multiple types, it has to guess at the type most likely to be supported by the server.
> SCRAM allows the server to read the client's channel binding type. Ideally, the server would then select the matching channel binding type if it is available, instead of querying for it ahead of time.
> So I propose the following:
> # On the SCRAM client, continue to use the ChannelBindingCallback to choose the binding type and data.
> # Introduce a callback type which allows a mechanism participant to provide a list of available channel binding types.
> # On the SCRAM server, instead of using ChannelBindingCallback to select a binding type *and* acquire the binding data, use this channel binding types callback to acquire the set of available channel bindings within the server factory.
> # On the SCRAM server, validate the client's selected binding type against the set of available channel bindings.
> # Change the ChannelBindingCallback contract, so that if a binding type name is already provided, the corresponding binding data should be provided (or an exception thrown). If no channel binding type name is given, then the callback continues to function as it does today, where a type is chosen and provided along with its data.
> # On the SCRAM server, use the modified ChannelBindingCallback contract to acquire the binding data for a pre-selected channel binding type.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (ELY-375) Server-side channel binding can cause mismatches
by David Lloyd (JIRA)
David Lloyd created ELY-375:
-------------------------------
Summary: Server-side channel binding can cause mismatches
Key: ELY-375
URL: https://issues.jboss.org/browse/ELY-375
Project: WildFly Elytron
Issue Type: Bug
Components: Authentication Mechanisms, Callbacks
Reporter: David Lloyd
Fix For: 1.1.0.Final
At present, the client and the server both locally query their connection situation to determine whether channel binding aware mechanisms should be made available for authentication. This is done by handling a {{ChannelBindingCallback}} and letting the callback handler determine what type of channel binding should be used, and what the data is.
However, this strategy fails if the client and server choose a different channel binding type, which is very likely to happen if at any point JSSE begins support for acquisition of the tls-unique channel binding data. A newer JDK would have tls-unique data, but an older JDK might only have tls-server-end-point available, resulting in a channel-binding-mismatch type error.
SCRAM allows the client to specify one channel binding type. So if the client supports multiple types, it has to guess at the type most likely to be supported by the server.
SCRAM allows the server to read the client's channel binding type. Ideally, the server would then select the matching channel binding type if it is available, instead of querying for it ahead of time.
So I propose the following:
# On the SCRAM client, continue to use the ChannelBindingCallback to choose the binding type and data.
# Introduce a callback type which allows a mechanism participant to provide a list of available channel binding types.
# On the SCRAM server, use the ChannelBindingCallback to acquire the binding data for the already-selected channel binding type.
#
#
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5716) Wrong handling of request context for remote EJB calls
by Ste Gr (JIRA)
[ https://issues.jboss.org/browse/WFLY-5716?page=com.atlassian.jira.plugin.... ]
Ste Gr commented on WFLY-5716:
------------------------------
I've looked through the CDI spec (1.0, 1,1 and 1.2) and in chapter *6.7.1. Request context lifecycle* it is clearly written, that the request context has to be created when a remote EJB invocation is made and that the context must be destroyed again when the EJB invocation finishes.
> Wrong handling of request context for remote EJB calls
> ------------------------------------------------------
>
> Key: WFLY-5716
> URL: https://issues.jboss.org/browse/WFLY-5716
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 9.0.0.Final, 10.0.0.CR4
> Reporter: Ste Gr
> Assignee: Stuart Douglas
>
> Two applications deployed to Wildfly. The first one provides a singleton remote ejb which uses request scoped beans (in this case a RESOURCE_LOCAL entity manager manged by a CDI producer/disposer, but +all+ request scoped beans are affected). The second application uses that EJB to get some data only accessible by the first application.
> A request is made to the second app from a browser. The app will get the remote EJB and invokes two methods on it. The first method produces the entity manager, accesses the database and returns the result. The entity manager will be disposed again. The second method won't produce a new entity manager but tries to re-use the one from the previous invokation. This fails as the entity manager was disposed.
> If the same use-case is made using the first app everythings works as desired. But it doesn't look right (or the request context is joined because it is the same application). It produces the the entity manager on the first invocation and closes it as soon as the whole request made from the browser is completed. Thats why the second invokation has a valid entity manager to work with.
> I don't know the spec but:
> - either the first EJB invokation from second app to first app is not allowed to dispose the request context (all the request scoped beans)
> - or each invokation must get its own request context (entity manager must be produced and disposed again).
> I've made a [stackoverflow thread|http://stackoverflow.com/q/33826720/1741604] which shows some code examples.
> (JBoss AS 7.1.3.Final is also affected but it is not available in 'affected version/s')
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1147) Eliminate ProcessController
by David Lloyd (JIRA)
David Lloyd created WFCORE-1147:
-----------------------------------
Summary: Eliminate ProcessController
Key: WFCORE-1147
URL: https://issues.jboss.org/browse/WFCORE-1147
Project: WildFly Core
Issue Type: Task
Components: Server
Reporter: David Lloyd
We should eliminate ProcessController and directly have the HC control the servers. This should greatly simplify the code and add more power and flexibility to the management and lifecycle of server JVMs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1146) Research behavior of fork with ProcessBuilder on modern JVMs
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1146?page=com.atlassian.jira.plugi... ]
David Lloyd moved WFLY-3202 to WFCORE-1146:
-------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1146 (was: WFLY-3202)
> Research behavior of fork with ProcessBuilder on modern JVMs
> ------------------------------------------------------------
>
> Key: WFCORE-1146
> URL: https://issues.jboss.org/browse/WFCORE-1146
> Project: WildFly Core
> Issue Type: Task
> Reporter: David Lloyd
>
> Right now our Process Controller exists for two primary reasons:
> # fork() misbehaves for large processes on some OSes, causing leaks or crashes
> # if the HC crashes, the PC can respawn it
> We have never (afaik) seen #2 happen. We need to verify whether #1 is still true on modern JVMs on the following operating systems:
> * Linux
> * Solaris
> * IBM OSes
> * Windows
> * BSDs
> * Mac OS X
> Test by creating processes with large heap and lots of concurrent file descriptor activity while forking to see what happens.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-1145:
-------------------------------------
Also want to clarify that this doesn't have to be serialization. It could be protobuf or similar, any number of marshalling formats, or just keep it as streams of DMR-based operations and results.
> Review of HostController / Application Server Remoting connections
> ------------------------------------------------------------------
>
> Key: WFCORE-1145
> URL: https://issues.jboss.org/browse/WFCORE-1145
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha1
>
>
> Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access.
> The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5716) Wrong handling of request context for remote EJB calls
by Ste Gr (JIRA)
[ https://issues.jboss.org/browse/WFLY-5716?page=com.atlassian.jira.plugin.... ]
Ste Gr updated WFLY-5716:
-------------------------
Description:
Two applications deployed to Wildfly. The first one provides a singleton remote ejb which uses request scoped beans (in this case a RESOURCE_LOCAL entity manager manged by a CDI producer/disposer, but +all+ request scoped beans are affected). The second application uses that EJB to get some data only accessible by the first application.
A request is made to the second app from a browser. The app will get the remote EJB and invokes two methods on it. The first method produces the entity manager, accesses the database and returns the result. The entity manager will be disposed again. The second method won't produce a new entity manager but tries to re-use the one from the previous invokation. This fails as the entity manager was disposed.
If the same use-case is made using the first app everythings works as desired. But it doesn't look right (or the request context is joined because it is the same application). It produces the the entity manager on the first invocation and closes it as soon as the whole request made from the browser is completed. Thats why the second invokation has a valid entity manager to work with.
I don't know the spec but:
- either the first EJB invokation from second app to first app is not allowed to dispose the request context (all the request scoped beans)
- or each invokation must get its own request context (entity manager must be produced and disposed again).
I've made a [stackoverflow thread|http://stackoverflow.com/q/33826720/1741604] which shows some code examples.
(JBoss AS 7.1.3.Final is also affected but it is not available in 'affected version/s')
was:
Two applications deployed to Wildfly. The first one provides a singleton remote ejb which uses request scoped beans (in this case a RESOURCE_LOCAL entity manager manged by a CDI producer/disposer, but +all+ request scoped beans are affected). The second application uses that EJB to get some data only accessible by the first application.
A request is made to the second app from a browser. The app will get the remote EJB and invokes two methods on it. The first method produces the entity manager, accesses the database and returns the result. The entity manager will be disposed again. The second method won't produce a new entity manager but tries to re-use the one from the previous invokation. This fails as the entity manager was disposed.
If the same use-case is made using the first app everythings works as desired. But it doesn't look right (or the request context is joined because it is the same application). It produces the the entity manager on the first invocation and closes it as soon as the whole request made from the browser is completed. Thats why the second invokation has a valid entity manager to work with.
I don't know the spec but:
- either the first EJB invokation from second app to first app is not allowed to dispose the request context (all the request scoped beans)
- or each invokation must get its own request context (entity manager must be produced and disposed again).
I've made a [stackoverflow thread|http://stackoverflow.com/q/33826720/1741604] which shows some code examples.
> Wrong handling of request context for remote EJB calls
> ------------------------------------------------------
>
> Key: WFLY-5716
> URL: https://issues.jboss.org/browse/WFLY-5716
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 9.0.0.Final, 10.0.0.CR4
> Reporter: Ste Gr
> Assignee: Stuart Douglas
>
> Two applications deployed to Wildfly. The first one provides a singleton remote ejb which uses request scoped beans (in this case a RESOURCE_LOCAL entity manager manged by a CDI producer/disposer, but +all+ request scoped beans are affected). The second application uses that EJB to get some data only accessible by the first application.
> A request is made to the second app from a browser. The app will get the remote EJB and invokes two methods on it. The first method produces the entity manager, accesses the database and returns the result. The entity manager will be disposed again. The second method won't produce a new entity manager but tries to re-use the one from the previous invokation. This fails as the entity manager was disposed.
> If the same use-case is made using the first app everythings works as desired. But it doesn't look right (or the request context is joined because it is the same application). It produces the the entity manager on the first invocation and closes it as soon as the whole request made from the browser is completed. Thats why the second invokation has a valid entity manager to work with.
> I don't know the spec but:
> - either the first EJB invokation from second app to first app is not allowed to dispose the request context (all the request scoped beans)
> - or each invokation must get its own request context (entity manager must be produced and disposed again).
> I've made a [stackoverflow thread|http://stackoverflow.com/q/33826720/1741604] which shows some code examples.
> (JBoss AS 7.1.3.Final is also affected but it is not available in 'affected version/s')
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (DROOLS-985) Loaded wrong version's jar file after restarting kie-server.
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-985?page=com.atlassian.jira.plugin... ]
Edson Tirelli closed DROOLS-985.
--------------------------------
Fix Version/s: 6.3.0.Final
Resolution: Rejected
Closing the ticket. Reopen and provide additional information on how to reproduce if you still think it is a problem.
> Loaded wrong version's jar file after restarting kie-server.
> ------------------------------------------------------------
>
> Key: DROOLS-985
> URL: https://issues.jboss.org/browse/DROOLS-985
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Environment: CentOS
> WAS : wildfly-8.2.1.Final
> Drools : 6.3.0.Final
> Reporter: hoon lee
> Assignee: Edson Tirelli
> Fix For: 6.3.0.Final
>
>
> 1. Start unmanaged kie-server
> 2. Create a container
> name : test
> kjar : test:test-rule:1.0.0
> 3. update & release (kjar)
> name : test
> kjar : test:test-rule:1.0.1
> 4. Restart unmanaged kie-server
> * Issue
> => Container 'test' is automatically started and load a 'test-rule:1.0.0' (not 1.0.1)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (DROOLS-985) Loaded wrong version's jar file after restarting kie-server.
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-985?page=com.atlassian.jira.plugin... ]
Edson Tirelli commented on DROOLS-985:
--------------------------------------
Did you call the API on the kie-server to upgrade to 1.0.1?
Restarting the server will indeed simply reload the same jar it was using before the restart, and that is correct. If you want the server to upgrade to a different version, you have to call the API to do so.
> Loaded wrong version's jar file after restarting kie-server.
> ------------------------------------------------------------
>
> Key: DROOLS-985
> URL: https://issues.jboss.org/browse/DROOLS-985
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Environment: CentOS
> WAS : wildfly-8.2.1.Final
> Drools : 6.3.0.Final
> Reporter: hoon lee
> Assignee: Edson Tirelli
>
> 1. Start unmanaged kie-server
> 2. Create a container
> name : test
> kjar : test:test-rule:1.0.0
> 3. update & release (kjar)
> name : test
> kjar : test:test-rule:1.0.1
> 4. Restart unmanaged kie-server
> * Issue
> => Container 'test' is automatically started and load a 'test-rule:1.0.0' (not 1.0.1)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5716) Wrong handling of request context for remote EJB calls
by Ste Gr (JIRA)
Ste Gr created WFLY-5716:
----------------------------
Summary: Wrong handling of request context for remote EJB calls
Key: WFLY-5716
URL: https://issues.jboss.org/browse/WFLY-5716
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, EJB
Affects Versions: 10.0.0.CR4, 9.0.0.Final
Reporter: Ste Gr
Assignee: Stuart Douglas
Two applications deployed to Wildfly. The first one provides a singleton remote ejb which uses request scoped beans (in this case a RESOURCE_LOCAL entity manager manged by a CDI producer/disposer, but +all+ request scoped beans are affected). The second application uses that EJB to get some data only accessible by the first application.
A request is made to the second app from a browser. The app will get the remote EJB and invokes two methods on it. The first method produces the entity manager, accesses the database and returns the result. The entity manager will be disposed again. The second method won't produce a new entity manager but tries to re-use the one from the previous invokation. This fails as the entity manager was disposed.
If the same use-case is made using the first app everythings works as desired. But it doesn't look right (or the request context is joined because it is the same application). It produces the the entity manager on the first invocation and closes it as soon as the whole request made from the browser is completed. Thats why the second invokation has a valid entity manager to work with.
I don't know the spec but:
- either the first EJB invokation from second app to first app is not allowed to dispose the request context (all the request scoped beans)
- or each invokation must get its own request context (entity manager must be produced and disposed again).
I've made a [stackoverflow thread|http://stackoverflow.com/q/33826720/1741604] which shows some code examples.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months