[
https://issues.apache.org/jira/browse/QPID-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17503317#comment-17503317
]
ASF subversion and git services commented on QPID-8566:
-------------------------------------------------------
Commit 58b1b3e961c4259956d084bc130ba4bc23fdb468 in qpid-broker-j's branch
refs/heads/main from Daniil Kirilyuk
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=58b1b3e ]
QPID-8566: [Broker-J] Implement composite authentication provider (#118)
Co-authored-by: aw924 <daniil.kiril...@deutsche-boerse.com>
> [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
> Priority: Minor
>
> 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.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
