Daniil Kirilyuk created QPID-8566:
-------------------------------------
Summary: [Broker-J] Implement composite authentication provider
Key: QPID-8566
URL: https://issues.apache.org/jira/browse/QPID-8566
Project: Qpid
Issue Type: Improvement
Components: Broker-J
Affects Versions: qpid-java-broker-8.0.6
Reporter: Daniil Kirilyuk
To make it possible to perform authentication either against the local
file-based database of users or against LDAP, as [suggested
|https://lists.apache.org/thread.html/r3b66d33c03e10ded626d020eecdfdf3f661dd12e2d54f0619abe4d03%40%3Cusers.qpid.apache.org%3E]in
Qpid mailing list, new composite authentication provider should be developed.
It should contain list of delegate authentication providers, which will be
assessed one by one during authentication process until first successful
authentication or until all authentication attempts fail. Supported delegate
types could be implementations of UsernamePasswordAuthenticationProvider
(MD5AuthenticationProvider, PlainAuthenticationProvider,
SimpleLDAPAuthenticationManager, ScramSHA1AuthenticationManager and
ScramSHA256AuthenticationManager).
As composite authentication manager will work with several user data sources
and should support SASL interactions, it will be limited to authenticate client
against first delegate containing authenticated username. I.e. when there are
several delegates with users having same usernames but different passwords, it
will be possible to authenticate client against the first delegate with the
matching username.
Composite authentication provider should have property - "delegates", which
will contain comma separated list of delegate authentication provider names.
Each delegate authentication provider has its own supported SASL mechanisms:
MD5 => ["PLAIN", "CRAM-MD5-HASHED", "CRAM-MD5-HEX"]
Plain => ["PLAIN", "CRAM-MD5", "SCRAM-SHA-1", "SCRAM-SHA-256"]
SCRAM-SHA-1 => ["SCRAM-SHA-1"]
SCRAM-SHA-256 => ["SCRAM-SHA-256"]
SimpleLDAP => ["PLAIN"]
Composite authentication providers will expose available SASL mechanisms of all
configured delegates, but it should be considered, that depending on the
delegate types configured, authentication process may require client to use
"amqp.saslMechanisms" property for authentication.
Example:
Composite provider has 2 delegates: SCRAM-SHA-256 (contains user "scram-user")
and SimpleLDAP (contains user "ldap-user"). When client establishes connection,
most secure SASL mechanism is chosen, it will be SCRAM-SHA-256, meaning that
scram-user will be able to authenticate and ldap-user will fail. To make
possible for ldap-user to authenticate against SimpleLDAP provider, it would be
necessary for client to specify "amqp.saslMechanisms=PLAIN" for ignoring
SCRAM-SHA-256 mechanism and authenticate using PLAIN mechanism.
Another limitation is the possible name collision: when two delegate providers
contain users with same names (but different passwords), it will be possible to
authenticate only for the user defined in the delegate coming first in the list.
Example:
Composite provider has 2 delegates: Plain (contains user "test-user" with
password "password1") and SCRAM-SHA-256 (contains user with same username
"test-user" and different password "password2"). When test-user will try to
authenticate using "password2" credential, it will fail (although username /
password is correct in SCRAM-SHA-256 provider).
When using composite provider it should be avoided to configure users with same
usernames in delegate providers. Usernames should be unique for all composite
authentication provider delegates.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
