Previously nonces were stored in a global map which might not scale well due to some issues: 1. The map used the nonces as map keys. There were possible nonce collisions which required special handling. 2. The collision handling code was not thread safe. There were possible race conditions during concurrent modifications. 3. The map was shared and size limited. If there were a lot of users using the system, valid nonces could get pruned. 4. The map mapped the nonces to client certificates. This limited the possible authentication methods that could be supported. Now the code has been modified such that each user has a private map in the user's session to store the nonces. Additional locking has been implemented to protect against concurrent modifications. The map now uses the target of the operation as the map key, eliminating possible collisions and allowing the use of other authentication methods. Since this is a private map, it's not affected by the number of users using the system. Ticket #474 -- Endi S. Dewata
On 1/25/2013 2:18 PM, Endi Sukma Dewata wrote:
Previously nonces were stored in a global map which might not scale well due to some issues: 1. The map used the nonces as map keys. There were possible nonce collisions which required special handling. 2. The collision handling code was not thread safe. There were possible race conditions during concurrent modifications. 3. The map was shared and size limited. If there were a lot of users using the system, valid nonces could get pruned. 4. The map mapped the nonces to client certificates. This limited the possible authentication methods that could be supported.
Now the code has been modified such that each user has a private map in the user's session to store the nonces. Additional locking has been implemented to protect against concurrent modifications. The map now uses the target of the operation as the map key, eliminating possible collisions and allowing the use of other authentication methods. Since this is a private map, it's not affected by the number of users using the system.
Ticket #474
New patch attached. Fixed the session attribute name in ProfileReviewServlet.java. -- Endi S. Dewata
On 1/25/2013 3:22 PM, Endi Sukma Dewata wrote:
On 1/25/2013 2:18 PM, Endi Sukma Dewata wrote:
Previously nonces were stored in a global map which might not scale well due to some issues: 1. The map used the nonces as map keys. There were possible nonce collisions which required special handling. 2. The collision handling code was not thread safe. There were possible race conditions during concurrent modifications. 3. The map was shared and size limited. If there were a lot of users using the system, valid nonces could get pruned. 4. The map mapped the nonces to client certificates. This limited the possible authentication methods that could be supported.
Now the code has been modified such that each user has a private map in the user's session to store the nonces. Additional locking has been implemented to protect against concurrent modifications. The map now uses the target of the operation as the map key, eliminating possible collisions and allowing the use of other authentication methods. Since this is a private map, it's not affected by the number of users using the system.
Ticket #474
New patch attached. Fixed the session attribute name in ProfileReviewServlet.java.
Rebased on top of patch #204. Fixed exception type. -- Endi S. Dewata
Looks pretty good to me. Question: 1. What is the purpose of the isMemberOfSubsystemGroup() method, and why do we need it? Ade On Thu, 2013-01-31 at 09:37 -0600, Endi Sukma Dewata wrote:
On 1/25/2013 3:22 PM, Endi Sukma Dewata wrote:
On 1/25/2013 2:18 PM, Endi Sukma Dewata wrote:
Previously nonces were stored in a global map which might not scale well due to some issues: 1. The map used the nonces as map keys. There were possible nonce collisions which required special handling. 2. The collision handling code was not thread safe. There were possible race conditions during concurrent modifications. 3. The map was shared and size limited. If there were a lot of users using the system, valid nonces could get pruned. 4. The map mapped the nonces to client certificates. This limited the possible authentication methods that could be supported.
Now the code has been modified such that each user has a private map in the user's session to store the nonces. Additional locking has been implemented to protect against concurrent modifications. The map now uses the target of the operation as the map key, eliminating possible collisions and allowing the use of other authentication methods. Since this is a private map, it's not affected by the number of users using the system.
Ticket #474
New patch attached. Fixed the session attribute name in ProfileReviewServlet.java.
Rebased on top of patch #204. Fixed exception type.
_______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
On 2/4/2013 9:49 AM, Ade Lee wrote:
Looks pretty good to me.
Question: 1. What is the purpose of the isMemberOfSubsystemGroup() method, and why do we need it?
The original code checks whether the user specified in the client certificate belongs to the "Subsystem Group". If it does, the code will skip nonce verification. I suppose this is used by internal PKI operations which do not require 2-step processes using nonces. The isMemberOfSubsystemGroup() is a method that encapsulates the above logic, and it's created to separate the logic from nonce validation which should not be dependent on client certificates. -- Endi S. Dewata
OK - I did not see that code in the original validateNonce() function. ACK On Mon, 2013-02-04 at 10:24 -0600, Endi Sukma Dewata wrote:
On 2/4/2013 9:49 AM, Ade Lee wrote:
Looks pretty good to me.
Question: 1. What is the purpose of the isMemberOfSubsystemGroup() method, and why do we need it?
The original code checks whether the user specified in the client certificate belongs to the "Subsystem Group". If it does, the code will skip nonce verification. I suppose this is used by internal PKI operations which do not require 2-step processes using nonces.
The isMemberOfSubsystemGroup() is a method that encapsulates the above logic, and it's created to separate the logic from nonce validation which should not be dependent on client certificates.
-- Endi S. Dewata
participants (2)
-
Ade Lee -
Endi Sukma Dewata