<div>In addition to the previous questions, is it possible to configure the auth challenge on the broker side to be vhost specific? For example, clients connecting to vhost 1 should be taken down the aforementioned LDAP + Radius path, but clients connecting to vhost 2 can just be authenticated with a plain LDAP lookup.
                </div><div><br></div><div>Or does the SASL handshake occur before the client presents the target vhost to the broker - in which case I presume you would have to encapsulate this information into the custom SASL mechanism and evaluate it selectively in the custom auth plugin that wraps Radius and LDAP (as discussed previously)?</div>
                <div></div>
                 
                <p style="color: #A0A0A8;">On Friday, 11 January 2013 at 18:02, Jerry Kuch wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div><br><br><div>On Fri, Jan 11, 2013 at 9:47 AM, Ben Hood <span dir="ltr">&lt;<a href="mailto:0x6e6562@gmail.com" target="_blank">0x6e6562@gmail.com</a>&gt;</span> wrote:<br><blockquote type="cite"><div>

                <div><br></div><div>Can this also be made to work in conjunction with an LDAP provider, i.e. by chaining the supported LDAP backend with a custom backend to additionally validate the the token? I wondering whether you can require the client to answer both a username/password challenge (evaluated by the supported LDAP auth backend) as well as having the token checked by the the custom backend? Does the protocol and wiring flow allow for the LDAP backend to get re-used in this way or would you need to implement the custom backend that wraps the lookup against the LDAP directory and the lookup against the Radius server?</div>
</div></blockquote><div><br></div><div>If I recall correctly, one backend or the other would have to know about the other one and take care of the chaining rather than something like this being possible in the Rabbit configuration. &nbsp;The backend chosen to go with a given connection is basically the first one in the rabbitmq.config file's list of backends that succeeds as they're tried in order, and is bound irrevocably to that session thereafter.</div>
<div><br></div><div>Pursuing this outcome you might be able to call into specific parts of the LDAP backend as helpers, but a good hunk of your hybrid auth logic would be in your plugin itself.</div><div><br></div></div>
</div><div><div>_______________________________________________</div><div>rabbitmq-discuss mailing list</div><div><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a></div><div><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a></div></div></div></span>
                 
                 
                 
                 
                </blockquote>
                 
                <div>
                    <br>
                </div>