qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aidan Skinner" <ai...@apache.org>
Subject Re: c++ broker authentication
Date Mon, 14 Apr 2008 19:21:45 GMT
On Mon, Apr 14, 2008 at 7:31 PM, Ted Ross <tross@redhat.com> wrote:

>  This (much needed) new feature means that the command-line utilities
> (qpid-config, qpid-route, etc.) now need to provide authentication
> credentials to the broker when establishing the AMQP connection for
> management.  It is an easy matter to provide credentials in option switches
> or interactively through a prompt.  However this is detrimental to
> scripting.  It is unacceptable to require passwords to appear in script
> files and it is equally unacceptable for each line of a script to
> interactively prompt the user.


>  2) Provide a facility for a user to "log in" once by supplying plain
> credentials and storing them securely in the user's private directory.  The
> qpid utilities could then check for stored credentials in lieu of supplied
> credentials.  A Kerberos-5 implementation will eventually provide this kind
> of single-sign-on capability but for PLAIN authentication, explicit storage
> would be needed.  Perhaps we should just hurry up and implement GSSAPI/Krb5.

This should be optional, and I definitely don't think it should do
this by default - it's the sort of thing that users and developers
think is great but makes sysadmins and security types go a funny shade
of purple. I particularly hate how svn does this and doesn't tell you
it's doing it.

>  3) Build the client in a two-tiered architecture where the first invocation
> of a utility (for a process) would spawn a detached client using supplied
> credentials.  This detached process would then connect to the broker and
> linger for a period of time handling traffic from subsequent utilities from
> the same shell process.  Once idle for a period of time (say 5 minutes), the
> connection process would disconnect from the broker and terminate.

I quite like this, it could open a unix socket that only that user can
read/write too a la ssh-agent. If you combined all the tools into
different commands you could have something logical like:

qpid login user@broker # prompts for password, sets QPID_LOGIN_SOCK
qpid config
qpid route
qpid logout # closes socket

- Aidan

aim/y!:aidans42 g:aidan.skinner@gmail.com
"We belong to nobody and nobody belongs to us. We don't even belong to
each other."

View raw message