[
https://issues.apache.org/jira/browse/QPID-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved QPID-4676.
----------------------------------
Resolution: Fixed
> [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
> Assignee: Robbie Gemmell
> Priority: Minor
> Fix For: 0.22
>
> Attachments: QPID-4676.patch, QPID-4676-systest.patch
>
>
> 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]
