You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Aidan Skinner <ai...@apache.org> on 2009/01/21 18:29:46 UTC
Java authorization plugins
In my continuining quest to make the java broker a pluggable,
maleable, customisable swiss army knife of a message broker, I've been
thinking about making our authorization (not authentication)
mechanisms pluggable. I've put up a quick sketch ritchiem and I hashed
out at http://cwiki.apache.org/confluence/display/qpid/Java+authorization+plugins
Comments gratefully recieved.
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Java authorization plugins
Posted by Aidan Skinner <ai...@apache.org>.
I don't want to support api yet, so i'm not concerned about
brittleness at this point. It's mostly for sanity and to get to a
point where we could use contributed stuff if necessary. I agree that
it's still a bit early to be making those kind of promises. I
certainly imagine that things will change a few times while we're
adding multiprotocol support.
On 1/21/09, Rafael Schloming <ra...@redhat.com> wrote:
> Aidan Skinner wrote:
>> In my continuining quest to make the java broker a pluggable,
>> maleable, customisable swiss army knife of a message broker, I've been
>> thinking about making our authorization (not authentication)
>> mechanisms pluggable. I've put up a quick sketch ritchiem and I hashed
>> out at
>> http://cwiki.apache.org/confluence/display/qpid/Java+authorization+plugins
>>
>> Comments gratefully recieved.
>
> I think if you don't want your plugins to be somewhat brittle and tied
> to a particular qpid release, then you need a more abstract interface
> for them. It's quite likely something like allowBind(...) will make no
> sense in the future.
>
> Do we have a demand for a publicly supported extension point for this
> sort of thing? I tend to think this sort of thing exposes us to more
> backwards compatibility issues as we move forward, so my inclination is
> to be quite careful with what we expose as a supported API.
>
> Of course if the intent is to simply refactor the existing private code
> for our own sanity and not make public APIs, then that's another matter.
>
> --Rafael
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Sent from Google Mail for mobile | mobile.google.com
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Java authorization plugins
Posted by Rafael Schloming <ra...@redhat.com>.
Aidan Skinner wrote:
> In my continuining quest to make the java broker a pluggable,
> maleable, customisable swiss army knife of a message broker, I've been
> thinking about making our authorization (not authentication)
> mechanisms pluggable. I've put up a quick sketch ritchiem and I hashed
> out at http://cwiki.apache.org/confluence/display/qpid/Java+authorization+plugins
>
> Comments gratefully recieved.
I think if you don't want your plugins to be somewhat brittle and tied
to a particular qpid release, then you need a more abstract interface
for them. It's quite likely something like allowBind(...) will make no
sense in the future.
Do we have a demand for a publicly supported extension point for this
sort of thing? I tend to think this sort of thing exposes us to more
backwards compatibility issues as we move forward, so my inclination is
to be quite careful with what we expose as a supported API.
Of course if the intent is to simply refactor the existing private code
for our own sanity and not make public APIs, then that's another matter.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org