[ https://issues.apache.org/jira/browse/QPID-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robbie Gemmell updated QPID-4676: --------------------------------- Fix Version/s: (was: Future) 0.23 > [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.23 > > Attachments: QPID-4676.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: per...@example.com > 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: per...@example.com > 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org