JAkub Scholz created QPID-4676:
----------------------------------
Summary: [Java Broker] SSL Client Authentication with username
constructed in the same way as on C++ broker
Key: QPID-4676
URL: https://issues.apache.org/jira/browse/QPID-4676
Project: Qpid
Issue Type: Improvement
Components: Java Broker
Reporter: JAkub Scholz
Priority: Minor
Fix For: Future
The current versions of both the Java broker and the C++ broker support
EXTERNAL authentication mechanism / SSL Client Authentication. Nevertheless the
implementations are not fully identical. One of the differences is the way the
usernames are constructed for the authenticated connections.
The C++ broker takes the CN of the certificate (+ eventually the domain
components / DCs) and creates a username as <CN>@<DC1>.<DC2>.<DC3>....<DCN>. In
case there are no DCs, only the CN is used. On the other hand, the Java broker
takes the full distinguished name as the username.
Example 1:
DN: CN=person
C++ username: person
Java username: CN=person
Example 2:
DN: CN=person,DC=example,DC=com
C++ username: [email protected]
Java username: CN=person,DC=example,DC=com
Example 3:
DN: CN=person,DC=example,DC=com,O=My Company Ltd,L=Newbury,ST=Berkshire,C=GB
C++ username: [email protected]
Java username: CN=person,DC=example,DC=com,O=My Company
Ltd,L=Newbury,ST=Berkshire,C=GB
This difference between C++ and Java broker makes it more complicated to
migrate between the different brokers. Also, the particular implementation in
Java can make it a bit more complicated to use the SSL Client Authentication in
some cases.
Therefore I implemented an enhancement which adds a possibility to the Java
broker to construct the usernames in the same way the C++ broker does. I added
a new configuration attribute "useCNAsUsername" for the
ExternalAuthenticationProvider / Manager which allows switching between the
current DN based usernames and the CN based usernames. By default, the old
behaviour is used. The setting is passed from the ExternalAuthenticationManager
to the ExternalSaslServer, which (in case the useCNAsUsername is switched ON)
constructs the new username and returns it using the UsernamePrinciple. I also
added some unit tests to cover the new functionality.
It would be great if someone can have a look at the attached patch and
eventually provide me with some review comments. One of the areas where I'm not
entirely sure about the patch is the way it handles the configuration parameter
from the JSON configuration. It is also no entirely clear to me what is the
strategy for naming the parameters - it seems to be kind of a mixture of short
names, long names, lower-case only, camel-case etc.
I didn't added any new systests to cover this feature - I have not really an
idea how to implement them. Especially how to get the authenticated username
once connected. If you point me in some direction, I can have a look at it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
