[ https://issues.apache.org/jira/browse/ARTEMIS-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16118701#comment-16118701 ]
ASF subversion and git services commented on ARTEMIS-1264: ---------------------------------------------------------- Commit 9fedb47c400b9a00dec08b8f3bc280fe674ad915 in activemq-artemis's branch refs/heads/master from [~gtully] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=9fedb47 ] [ARTEMIS-1310] [ARTEMIS-1264] consolidate configuration to require login configuration scope > Client authentication via Kerberos TLS Cipher Suites (RFC 2712) > --------------------------------------------------------------- > > Key: ARTEMIS-1264 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1264 > Project: ActiveMQ Artemis > Issue Type: New Feature > Affects Versions: 2.1.0 > Reporter: Gary Tully > Assignee: Gary Tully > Fix For: 2.2.0 > > > Allow a client authenticated with a kerberos credential to authenticate to > the broker using SSL via the Kerberos cipher suites. > next steps: > - -ensure mapping from kerberos principal to broker identity is locked down- > -- https://github.com/apache/activemq-artemis/pull/1388 > - -ensure jms client config is trivial- > -- the connector properties can be configured in the same way as for core. > - -validate broker side ticket expiry and renewal- > - work with qpid-jms to validate amqp client (on hold) > - validate with non java - proton-c client ({color:red}problem{color}) > Interop with non java clients is a problem. OpenSSL [has removed > support|http://openssl.6102.n7.nabble.com/openssl-users-Kerberos-tp57906p58095.html] > for [rfc2712|https://www.ietf.org/rfc/rfc2712.txt]. > While reusing the TLS handshake was a good idea at the time; it has issues > (non compatible impl between openssl and sun) and the world has moved on to > layering authentication over TLS rather than with. > This makes sense b/c kerberos does two things, authentication over an > insecure connection and session encryption over that connection. With rfc2712 > the available session encryption options are known to be insecure, best to > leave encryption entirely to TLS. > In a java only scenario (sun jdk on both ends), using this feature for > kerberos *authentication only* is viable. > For example, if clients use username/password for authentication and TLS to > encrypt the connection to secure the password, but don't care about > encrypting the rest of the data, there is some value here. > They can swap the username/password for a kerberos token and achieve > authentication. They will essentially drop encryption because the cypher in > use is insecure. Note a kerberos ticket is designed to be validated across an > insecure channel. > The modern approach is to layer kerberos authentication over TLS using > something like the GSSAPI and SASL. -- This message was sent by Atlassian JIRA (v6.4.14#64029)