[JBoss JIRA] (WFCORE-3273) sharedState is passed null by PluginAuthenticationCallbackHandler
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3273?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-3273:
-------------------------------------
Description:
oVirt's ovirt-engine uses an authorization plugin [1] for management interface that recently after upgrading to Wildfly 11 stopped working. The reason is the sharedState passed to the plugin's init method is now null.
A current workaround this would be to avoid adding to plugin into the shareState but that means any delegating plugin would fail to find this plugin and possibly other bad stuff I'm not aware of.
[1] https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manag...
was:
oVirt's ovirt-engine uses an authorization plugin [1] for management interface that recently after upgrading to Wildfly 11 stopped working. The reason is the sharedState passed to the plugin constructor is now null.
A current workaround this would be to avoid adding to plugin into the shareState but that means any delegating plugin would fail to find this plugin and possibly other bad stuff I'm not aware of.
[1] https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manag...
> sharedState is passed null by PluginAuthenticationCallbackHandler
> -----------------------------------------------------------------
>
> Key: WFCORE-3273
> URL: https://issues.jboss.org/browse/WFCORE-3273
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Environment: Fedora 26, using ovirt-engine-wildfly package
> Reporter: Roy Golan
> Assignee: Darran Lofthouse
>
> oVirt's ovirt-engine uses an authorization plugin [1] for management interface that recently after upgrading to Wildfly 11 stopped working. The reason is the sharedState passed to the plugin's init method is now null.
> A current workaround this would be to avoid adding to plugin into the shareState but that means any delegating plugin would fail to find this plugin and possibly other bad stuff I'm not aware of.
> [1] https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manag...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-1160) Elytron, SASL digest mechanism works only with MD5 hash function
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-1160?page=com.atlassian.jira.plugin.s... ]
Farah Juma resolved ELY-1160.
-----------------------------
Resolution: Rejected
Closing this one since the corresponding JBEAP issue was rejected since this is just a configuration issue. Using DIGEST-SHA, DIGEST-SHA-256, and DIGEST-SHA-512 does work properly.
> Elytron, SASL digest mechanism works only with MD5 hash function
> ----------------------------------------------------------------
>
> Key: ELY-1160
> URL: https://issues.jboss.org/browse/ELY-1160
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Martin Choma
> Priority: Critical
>
> Elytron SASL mechanism works only with MD5. When trying to use one of DIGEST-SHA, DIGEST-SHA-256, DIGEST-SHA-512 I get
> {code}
> ELY05055: [DIGEST-SHA-256] Authentication rejected (invalid proof)
> {code}
> I know these mechanisms are marked as tech preview [2], but should work.
> DIGEST hash function can make problems in fips environment, like this customer case [1] in case of HTTP DIGEST mechanism
> {code:title=server.log}
> 10:56:26,243 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Initialized connection from /127.0.0.1:39291 to /127.0.0.1:9990 with options {org.jboss.remoting3.RemotingOptions.SASL_PROTOCOL=>remote}
> 10:56:26,244 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Accepted connection from /127.0.0.1:39291 to localhost.localdomain/127.0.0.1:9990
> 10:56:26,250 TRACE [org.jboss.remoting.remote] (management I/O-2) Setting read listener to org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@63e189b6
> 10:56:26,252 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 28 bytes
> 10:56:26,252 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 10:56:26,261 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 10:56:26,262 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 10:56:26,262 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 59 bytes
> 10:56:26,262 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=55 cap=8192]
> 10:56:26,263 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=55 cap=8192]
> 10:56:26,263 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request
> 10:56:26,263 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1
> 10:56:26,263 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "cli-client"
> 10:56:26,263 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported
> 10:56:26,263 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.0.Beta22-redhat-1"
> 10:56:26,263 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40"
> 10:56:26,263 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40"
> 10:56:26,263 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service
> 10:56:26,264 TRACE [org.jboss.remoting.remote.server] (management I/O-2) No EXTERNAL mechanism due to lack of SSL
> 10:56:26,269 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism DIGEST-SHA-256
> 10:56:26,269 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 85 bytes
> 10:56:26,269 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 10:56:26,384 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 10:56:26,384 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 10:56:26,384 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 20 bytes
> 10:56:26,385 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=16 cap=8192]
> 10:56:26,385 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=16 cap=8192]
> 10:56:26,385 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received authentication request
> 10:56:26,391 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback type='SASL' name='DIGEST-SHA-256' host-name='localhost.localdomain' protocol='remote'
> 10:56:26,392 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback type='SASL' name='DIGEST-SHA-256' host-name='localhost.localdomain' protocol='remote'
> 10:56:26,393 TRACE [org.wildfly.security] (management I/O-2) Handling AvailableRealmsCallback: realms = [ManagementRealm]
> 10:56:26,454 TRACE [org.jboss.remoting.endpoint] (management I/O-2) Allocated tick to 8 of endpoint "localhost:MANAGEMENT" <1f0d26e2> (opened org.jboss.remoting3.EndpointImpl$TrackingExecutor@55587716)
> 10:56:26,460 TRACE [org.jboss.remoting.remote.server] (management task-1) Server sending authentication challenge
> 10:56:26,461 TRACE [org.jboss.remoting.remote] (management task-1) Setting read listener to org.jboss.remoting3.remote.ServerConnectionOpenListener$Authentication@5a85277e
> 10:56:26,461 TRACE [org.jboss.remoting.endpoint] (management task-1) Resource closed count 00000007 of endpoint "localhost:MANAGEMENT" <1f0d26e2> (closed org.jboss.remoting3.EndpointImpl$TrackingExecutor@55587716)
> 10:56:26,461 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 118 bytes
> 10:56:26,462 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 10:56:29,472 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 10:56:29,473 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 10:56:29,473 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 324 bytes
> 10:56:29,473 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=320 cap=8192]
> 10:56:29,473 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=320 cap=8192]
> 10:56:29,473 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received authentication response
> 10:56:29,473 TRACE [org.jboss.remoting.endpoint] (management I/O-2) Allocated tick to 8 of endpoint "localhost:MANAGEMENT" <1f0d26e2> (opened org.jboss.remoting3.EndpointImpl$TrackingExecutor@55587716)
> 10:56:29,475 TRACE [org.wildfly.security] (management task-2) Handling RealmCallback: selected = [ManagementRealm]
> 10:56:29,475 TRACE [org.wildfly.security] (management task-2) Handling NameCallback: authenticationName = admin
> 10:56:29,476 TRACE [org.wildfly.security] (management task-2) Principal assigning: [admin], pre-realm rewritten: [admin], realm name: [ManagementRealm], post-realm rewritten: [admin], realm rewritten: [admin]
> 10:56:29,478 TRACE [org.wildfly.security] (management task-2) Handling CredentialCallback: failed to obtain credential
> 10:56:29,478 TRACE [org.wildfly.security] (management task-2) Handling RealmCallback: selected = [ManagementRealm]
> 10:56:29,478 TRACE [org.wildfly.security] (management task-2) Handling NameCallback: authenticationName = admin
> 10:56:29,483 TRACE [org.wildfly.security] (management task-2) Handling CredentialCallback: obtained credential: org.wildfly.security.credential.PasswordCredential@7917c4d1
> 10:56:29,485 TRACE [org.jboss.remoting.remote.server] (management task-2) Server sending authentication rejected: javax.security.sasl.SaslException: ELY05055: [DIGEST-SHA-256] Authentication rejected (invalid proof)
> at org.wildfly.security.sasl.digest.DigestSaslServer.validateDigestResponse(DigestSaslServer.java:279)
> 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.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:470)
> 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:745)
> 10:56:29,486 TRACE [org.wildfly.security] (management task-2) Handling AuthenticationCompleteCallback: fail
> 10:56:29,498 TRACE [org.jboss.remoting.remote] (management task-2) Setting read listener to org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@3770546b
> 10:56:29,498 TRACE [org.jboss.remoting.endpoint] (management task-2) Resource closed count 00000007 of endpoint "localhost:MANAGEMENT" <1f0d26e2> (closed org.jboss.remoting3.EndpointImpl$TrackingExecutor@55587716)
> 10:56:29,499 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 5 bytes
> 10:56:29,499 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 10:56:29,499 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 10:56:29,499 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 10:56:29,500 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 59 bytes
> 10:56:29,500 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=55 cap=8192]
> 10:56:29,500 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=55 cap=8192]
> 10:56:29,500 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request
> 10:56:29,500 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1
> 10:56:29,500 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "cli-client"
> 10:56:29,500 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported
> 10:56:29,500 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.0.Beta22-redhat-1"
> 10:56:29,500 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40"
> 10:56:29,500 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40"
> 10:56:29,500 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service
> 10:56:29,501 TRACE [org.jboss.remoting.remote.server] (management I/O-2) No EXTERNAL mechanism due to lack of SSL
> 10:56:29,502 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism DIGEST-SHA-256
> 10:56:29,502 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 85 bytes
> 10:56:29,502 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 10:56:29,503 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 10:56:29,503 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 10:56:29,503 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received EOF
> 10:56:29,503 TRACE [org.jboss.remoting.remote] (management I/O-2) Received connection end-of-stream
> {code}
> [1] https://access.redhat.com/support/cases/#/case/01761455
> [2] https://docs.google.com/document/d/1JelV424cHI1cr1BSH2MCXDAUlorGGJGca7uwZ...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JGRP-2218) New buffers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2218?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2218:
---------------------------
Description:
h3. Goal
Change payload in {{Message}} from byte[] arrays to a {{Buffer}} interface which can have multiple implementations.
h3. Motivation
Currently, having to pass a byte[] array to a message leads to unnecessary copying:
* When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
* When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
h3. Design
Instead of copying, the application creates an instance of {{Buffer}} and sets the buffer in {{Message}}. The {{Buffer}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of buffer implementations, e.g.
* {{ArrayBuffer}}: wraps a byte[] array with an offset and length
* {{NioDirectBuffer}}: wraps an NIO direct {{ByteBuffer}}
* {{NioHeapBuffer}}: wraps an NIO heap-based {{ByteBuffer}}
* {{CompositeBuffer}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
* {{IntBuffer}}: a single integer
* {{ObjectBuffer}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in buffers and they're only marshalled at the end (transport).
* {{PartialBuffer}}: a ref to a {{Buffer}}, with an offset and length
The {{Buffer}} interface has methods:
* {{size()}}
* {{writeTo(DataOutput)}}
* {{readFrom(DataInput)}}
* {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying buffer
and possibly also
* {{acquire()}} and
* {{release()}} (for ref-counting)
* {{copy()}}
Each buffer impl has an ID and it should be possible to register new impls. A {{BufferFactory}} maintains a mapping between IDs and impl classes.
When marshalling a {{Buffer}}, the ID is written first, followed by the buffer's {{writeTo()}} method. When reading buffers, the {{BufferFactory}} is used to create instances from IDs.
h4. Fragmentation
When fragmenting a buffer, the fragments are instances of {{PartialBuffer}} which maintains an offset and length over an underlying buffer. When marshalling a {{PartialBuffer}}, only the part between offset and offset+length is written to the output stream.
h4. Reference counting
If we implement ref-counting, then buffers can be reused as soon as the ref-count is 0. For example, when sending a message, the buffer's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the buffer cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the buffer cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
h4. Buffer management
When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{BufferManagement}} (or {{BufferPool}} component for a new buffer. A naive implementation might create a new buffer every time, and more sophisticated one might use a pool of buffers.
The {{BufferManagement}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of buffers: thus the creation of buffers by the application and of buffers received over the network can be controlled by the same buffer management impl.
h4. Misc
* Since this issue includes API changes, the version will be 5.0
was:
h3. Goal
Change payload in {{Message}} from byte[] arrays to a {{Buffer}} interface which can have multiple implementations.
h3. Motivation
Currently, having to pass a byte[] array to a message leads to unnecessary copying:
* When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
* When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
h3. Design
Instead of copying, the application creates an instance of {{Buffer}} and sets the buffer in {{Message}}. The {{Buffer}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of buffer implementations, e.g.
* {{ArrayBuffer}}: wraps a byte[] array with an offset and length
* {{NioDirectBuffer}}: wraps an NIO direct {{ByteBuffer}}
* {{NioHeapBuffer}}: wraps an NIO heap-based {{ByteBuffer}}
* {{CompositeBuffer}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
* {{IntBuffer}}: a single integer
* {{ObjectBuffer}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in buffers and they're only marshalled at the end (transport).
* {{PartialBuffer}}: a ref to a {{Buffer}}, with an offset and length
The {{Buffer}} interface has methods:
* {{size()}}
* {{writeTo(DataOutput)}}
* {{readFrom(DataInput)}}
* {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying buffer
and possibly also
* {{acquire()}} and
* {{release()}} (for ref-counting).
Each buffer impl has an ID and it should be possible to register new impls. A {{BufferFactory}} maintains a mapping between IDs and impl classes.
When marshalling a {{Buffer}}, the ID is written first, followed by the buffer's {{writeTo()}} method. When reading buffers, the {{BufferFactory}} is used to create instances from IDs.
h4. Fragmentation
When fragmenting a buffer, the fragments are instances of {{PartialBuffer}} which maintains an offset and length over an underlying buffer. When marshalling a {{PartialBuffer}}, only the part between offset and offset+length is written to the output stream.
h4. Reference counting
If we implement ref-counting, then buffers can be reused as soon as the ref-count is 0. For example, when sending a message, the buffer's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the buffer cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the buffer cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
h4. Buffer management
When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{BufferManagement}} (or {{BufferPool}} component for a new buffer. A naive implementation might create a new buffer every time, and more sophisticated one might use a pool of buffers.
The {{BufferManagement}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of buffers: thus the creation of buffers by the application and of buffers received over the network can be controlled by the same buffer management impl.
h4. Misc
* Since this issue includes API changes, the version will be 5.0
> New buffers
> -----------
>
> Key: JGRP-2218
> URL: https://issues.jboss.org/browse/JGRP-2218
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
>
> h3. Goal
> Change payload in {{Message}} from byte[] arrays to a {{Buffer}} interface which can have multiple implementations.
> h3. Motivation
> Currently, having to pass a byte[] array to a message leads to unnecessary copying:
> * When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
> * When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
> h3. Design
> Instead of copying, the application creates an instance of {{Buffer}} and sets the buffer in {{Message}}. The {{Buffer}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of buffer implementations, e.g.
> * {{ArrayBuffer}}: wraps a byte[] array with an offset and length
> * {{NioDirectBuffer}}: wraps an NIO direct {{ByteBuffer}}
> * {{NioHeapBuffer}}: wraps an NIO heap-based {{ByteBuffer}}
> * {{CompositeBuffer}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
> * {{IntBuffer}}: a single integer
> * {{ObjectBuffer}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in buffers and they're only marshalled at the end (transport).
> * {{PartialBuffer}}: a ref to a {{Buffer}}, with an offset and length
> The {{Buffer}} interface has methods:
> * {{size()}}
> * {{writeTo(DataOutput)}}
> * {{readFrom(DataInput)}}
> * {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying buffer
> and possibly also
> * {{acquire()}} and
> * {{release()}} (for ref-counting)
> * {{copy()}}
> Each buffer impl has an ID and it should be possible to register new impls. A {{BufferFactory}} maintains a mapping between IDs and impl classes.
> When marshalling a {{Buffer}}, the ID is written first, followed by the buffer's {{writeTo()}} method. When reading buffers, the {{BufferFactory}} is used to create instances from IDs.
> h4. Fragmentation
> When fragmenting a buffer, the fragments are instances of {{PartialBuffer}} which maintains an offset and length over an underlying buffer. When marshalling a {{PartialBuffer}}, only the part between offset and offset+length is written to the output stream.
> h4. Reference counting
> If we implement ref-counting, then buffers can be reused as soon as the ref-count is 0. For example, when sending a message, the buffer's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the buffer cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the buffer cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
> h4. Buffer management
> When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{BufferManagement}} (or {{BufferPool}} component for a new buffer. A naive implementation might create a new buffer every time, and more sophisticated one might use a pool of buffers.
> The {{BufferManagement}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of buffers: thus the creation of buffers by the application and of buffers received over the network can be controlled by the same buffer management impl.
> h4. Misc
> * Since this issue includes API changes, the version will be 5.0
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9251) Security context is not thread safe
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-9251?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-9251.
------------------------------------
Fix Version/s: 11.0.0.Final
Resolution: Rejected
> Security context is not thread safe
> -----------------------------------
>
> Key: WFLY-9251
> URL: https://issues.jboss.org/browse/WFLY-9251
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Environment: Windows, LInux
> Reporter: charles ghislain
> Assignee: Darran Lofthouse
> Labels: jaas, security, security-context, thread-safety, threads
> Fix For: 11.0.0.Final
>
> Attachments: wildfly-auth-overloader.js, wildflytestauthcontext-2.zip, wildflytestauthcontext.zip
>
>
> Using a custom JAAS login module, we sometimes fail to obtain the authenticated subject from the 'javax.security.auth.Subject.container' policy context. This appear to be related to the worker threads.
> See the reproduction steps below. When a wildfly instance attempts to authenticate 500 requests coming simultaneously, a bunch of them fail. If you configure wildfly to only use a single worker thread and a single task thread, this issue disappears.
> The issue is as follow:
> I login using HttpServletRequest#login.
> Right after that, login.getUserPrincipal return the correct principal.
> However, sometimes, PolicyContext.getContext("javax.security.auth.Subject.container") returns null. Right after the login.
> In our production app, PolicyContext.getContext("javax.security.auth.Subject.container") returns null during some EJB call, throwing random exceptions from various parts of the application.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9251) Security context is not thread safe
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-9251?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-9251:
----------------------------------------
+1 you must never use ClientLoginModule in a server side security domain used for application security, it pushes onto a stack during login but without the corresponding logout the pop never occurs - this will lead to an inconsistent stack.
> Security context is not thread safe
> -----------------------------------
>
> Key: WFLY-9251
> URL: https://issues.jboss.org/browse/WFLY-9251
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Environment: Windows, LInux
> Reporter: charles ghislain
> Assignee: Darran Lofthouse
> Labels: jaas, security, security-context, thread-safety, threads
> Fix For: 11.0.0.Final
>
> Attachments: wildfly-auth-overloader.js, wildflytestauthcontext-2.zip, wildflytestauthcontext.zip
>
>
> Using a custom JAAS login module, we sometimes fail to obtain the authenticated subject from the 'javax.security.auth.Subject.container' policy context. This appear to be related to the worker threads.
> See the reproduction steps below. When a wildfly instance attempts to authenticate 500 requests coming simultaneously, a bunch of them fail. If you configure wildfly to only use a single worker thread and a single task thread, this issue disappears.
> The issue is as follow:
> I login using HttpServletRequest#login.
> Right after that, login.getUserPrincipal return the correct principal.
> However, sometimes, PolicyContext.getContext("javax.security.auth.Subject.container") returns null. Right after the login.
> In our production app, PolicyContext.getContext("javax.security.auth.Subject.container") returns null during some EJB call, throwing random exceptions from various parts of the application.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3203) WildFlyTestRunner throws NullPointerException during stop intermittently
by Martin Stefanko (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3203?page=com.atlassian.jira.plugi... ]
Martin Stefanko reassigned WFCORE-3203:
---------------------------------------
Assignee: Martin Stefanko (was: Tomaz Cerar)
> WildFlyTestRunner throws NullPointerException during stop intermittently
> ------------------------------------------------------------------------
>
> Key: WFCORE-3203
> URL: https://issues.jboss.org/browse/WFCORE-3203
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Josef Cacek
> Assignee: Martin Stefanko
>
> There seems to be a synchronization issue in the WildFly TestRunner ({{Server}} class) in the wildfly-core testuite.
> I'm getting a {{NullPointerException}} intermittently during server stop:
> {noformat}
> Exception in thread "Thread-5" java.lang.NullPointerException
> at org.wildfly.core.testrunner.Server.lambda$stop$0(Server.java:205)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This is a testsuite issue which doesn't affect the test results themselves. Nevertheless it would be better to have clean runs without NPEs.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9251) Security context is not thread safe
by Rémy Delerue (JIRA)
[ https://issues.jboss.org/browse/WFLY-9251?page=com.atlassian.jira.plugin.... ]
Rémy Delerue edited comment on WFLY-9251 at 9/12/17 9:36 AM:
-------------------------------------------------------------
We disabled _ClientLoginModule_ and the issue seams to be resolved.
We think the following configuration is wrong:
{code:xml}
<security-domain name="TestSecurityDomain" cache-type="default">
<authentication>
<login-module code="be.test.TestLoginModule" flag="required"/>
<login-module code="org.jboss.security.ClientLoginModule" flag="optional"/>
</authentication>
</security-domain>
{code}
According to [wiki/ClientLoginModule|https://developer.jboss.org/wiki/ClientLoginModule], you can't have a _ClientLoginModule_ and the actual authentication module in the same security domain. We disabled our _ClientLoginModule_ and things seams better with good performances (that wasn't the case without the cache or with _synchronized_ blocks we tested out).
We'll enable it back if we really need it.
was (Author: clivia):
We disabled _ClientLoginModule_ and the issue seams to be resolved.
We think the following configuration is wrong:
{code:xml}
<security-domain name="TestSecurityDomain" cache-type="default">
<authentication>
<login-module code="be.test.TestLoginModule" flag="required"/>
<login-module code="org.jboss.security.ClientLoginModule" flag="optional"/>
</authentication>
</security-domain>
{code}
According to [wiki/ClientLoginModule|https://developer.jboss.org/wiki/ClientLoginModule], you can't have a _ClientLoginModule_ and the actual authentication module in the same security domain. We disabled our _ClientLoginModule_ and things seams better with good performances (that wasn't the case without the cache or with _synchronized_ blocks we tested out).
We'll enable it back if we really need it.
> Security context is not thread safe
> -----------------------------------
>
> Key: WFLY-9251
> URL: https://issues.jboss.org/browse/WFLY-9251
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Environment: Windows, LInux
> Reporter: charles ghislain
> Assignee: Darran Lofthouse
> Labels: jaas, security, security-context, thread-safety, threads
> Attachments: wildfly-auth-overloader.js, wildflytestauthcontext-2.zip, wildflytestauthcontext.zip
>
>
> Using a custom JAAS login module, we sometimes fail to obtain the authenticated subject from the 'javax.security.auth.Subject.container' policy context. This appear to be related to the worker threads.
> See the reproduction steps below. When a wildfly instance attempts to authenticate 500 requests coming simultaneously, a bunch of them fail. If you configure wildfly to only use a single worker thread and a single task thread, this issue disappears.
> The issue is as follow:
> I login using HttpServletRequest#login.
> Right after that, login.getUserPrincipal return the correct principal.
> However, sometimes, PolicyContext.getContext("javax.security.auth.Subject.container") returns null. Right after the login.
> In our production app, PolicyContext.getContext("javax.security.auth.Subject.container") returns null during some EJB call, throwing random exceptions from various parts of the application.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9251) Security context is not thread safe
by Rémy Delerue (JIRA)
[ https://issues.jboss.org/browse/WFLY-9251?page=com.atlassian.jira.plugin.... ]
Rémy Delerue edited comment on WFLY-9251 at 9/12/17 9:35 AM:
-------------------------------------------------------------
We disabled _ClientLoginModule_ and the issue seams to be resolved.
We think the following configuration is wrong:
{code:xml}
<security-domain name="TestSecurityDomain" cache-type="default">
<authentication>
<login-module code="be.test.TestLoginModule" flag="required"/>
<login-module code="org.jboss.security.ClientLoginModule" flag="optional"/>
</authentication>
</security-domain>
{code}
According to [wiki/ClientLoginModule|https://developer.jboss.org/wiki/ClientLoginModule], you can't have a _ClientLoginModule_ and the actual authentication module in the same security domain. We disabled our _ClientLoginModule_ and things seams better with good performances (that wasn't the case without the cache or with _synchronized_ blocks we tested out).
We'll enable it back if we really need it.
was (Author: clivia):
We disabled _ClientLoginModule_ and the issue seams to be resolved.
We think the following configuration is wrong:
<security-domain name="TestSecurityDomain" cache-type="default">
<authentication>
<login-module code="be.test.TestLoginModule" flag="required"/>
<login-module code="org.jboss.security.ClientLoginModule" flag="optional"/>
</authentication>
</security-domain>
According to [wiki/ClientLoginModule|https://developer.jboss.org/wiki/ClientLoginModule], you can't have _ClientLoginModule_ and the actual authentication module in the same security domain. We disabled _ClientLoginModule_ and thinks seams better with good performances (that wasn't the case without the cache or with _synchronized_ blocks we tested out).
We'll enable it back if we really need it.
> Security context is not thread safe
> -----------------------------------
>
> Key: WFLY-9251
> URL: https://issues.jboss.org/browse/WFLY-9251
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Environment: Windows, LInux
> Reporter: charles ghislain
> Assignee: Darran Lofthouse
> Labels: jaas, security, security-context, thread-safety, threads
> Attachments: wildfly-auth-overloader.js, wildflytestauthcontext-2.zip, wildflytestauthcontext.zip
>
>
> Using a custom JAAS login module, we sometimes fail to obtain the authenticated subject from the 'javax.security.auth.Subject.container' policy context. This appear to be related to the worker threads.
> See the reproduction steps below. When a wildfly instance attempts to authenticate 500 requests coming simultaneously, a bunch of them fail. If you configure wildfly to only use a single worker thread and a single task thread, this issue disappears.
> The issue is as follow:
> I login using HttpServletRequest#login.
> Right after that, login.getUserPrincipal return the correct principal.
> However, sometimes, PolicyContext.getContext("javax.security.auth.Subject.container") returns null. Right after the login.
> In our production app, PolicyContext.getContext("javax.security.auth.Subject.container") returns null during some EJB call, throwing random exceptions from various parts of the application.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9251) Security context is not thread safe
by Rémy Delerue (JIRA)
[ https://issues.jboss.org/browse/WFLY-9251?page=com.atlassian.jira.plugin.... ]
Rémy Delerue commented on WFLY-9251:
------------------------------------
We disabled _ClientLoginModule_ and the issue seams to be resolved.
We think the following configuration is wrong:
<security-domain name="TestSecurityDomain" cache-type="default">
<authentication>
<login-module code="be.test.TestLoginModule" flag="required"/>
<login-module code="org.jboss.security.ClientLoginModule" flag="optional"/>
</authentication>
</security-domain>
According to [wiki/ClientLoginModule|https://developer.jboss.org/wiki/ClientLoginModule], you can't have _ClientLoginModule_ and the actual authentication module in the same security domain. We disabled _ClientLoginModule_ and thinks seams better with good performances (that wasn't the case without the cache or with _synchronized_ blocks we tested out).
We'll enable it back if we really need it.
> Security context is not thread safe
> -----------------------------------
>
> Key: WFLY-9251
> URL: https://issues.jboss.org/browse/WFLY-9251
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Environment: Windows, LInux
> Reporter: charles ghislain
> Assignee: Darran Lofthouse
> Labels: jaas, security, security-context, thread-safety, threads
> Attachments: wildfly-auth-overloader.js, wildflytestauthcontext-2.zip, wildflytestauthcontext.zip
>
>
> Using a custom JAAS login module, we sometimes fail to obtain the authenticated subject from the 'javax.security.auth.Subject.container' policy context. This appear to be related to the worker threads.
> See the reproduction steps below. When a wildfly instance attempts to authenticate 500 requests coming simultaneously, a bunch of them fail. If you configure wildfly to only use a single worker thread and a single task thread, this issue disappears.
> The issue is as follow:
> I login using HttpServletRequest#login.
> Right after that, login.getUserPrincipal return the correct principal.
> However, sometimes, PolicyContext.getContext("javax.security.auth.Subject.container") returns null. Right after the login.
> In our production app, PolicyContext.getContext("javax.security.auth.Subject.container") returns null during some EJB call, throwing random exceptions from various parts of the application.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months