Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.1.0
-
None
-
None
Description
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 downensure 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 (problem)
Interop with non java clients is a problem. OpenSSL has removed support for rfc2712.
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.
Attachments
Issue Links
- is related to
-
ARTEMIS-3038 unwind defunct changes from ARTEMIS-1264
-
- Resolved
-
- is superceded by
-
ARTEMIS-1310 Provide GSSAPI (kerberos) SASL mechanism for AMQP
-
- Closed
-
- links to
