[Architecture] Removing config data from registry for BAM
srinath at wso2.com
Sun Feb 27 20:20:43 EST 2011
Let me try to summarize
For the Push case, BAM does not need to remember anything. Servers
call a BAM client, which send the message *directly* to BAM (No
eventing involved). We need server to server authentication, and we
can a) have user called BAM. We have to give a way to configure this
BAM users password within each server (e.g. from carbon.xml) or b)
have mutual authentication via SSL. We discussed similar case for
Cassandra integration with Thilina.
For the Pull case, BAM need to remember server Urls and there
passwords. I think, this data need to be replicated across the
cluster. We have two problems
1) How to share servers to be pulled across servers? In other words
how to store that data?
2) How do we make sure only one server is pulling? But if that server
failed, someone have to take over?
On Sun, Feb 27, 2011 at 8:16 PM, Tharindu Mathew <tharindu at wso2.com> wrote:
> On Sun, Feb 27, 2011 at 11:22 AM, Sanjiva Weerawarana <sanjiva at wso2.com>
>> On Sun, Feb 27, 2011 at 11:05 AM, Tharindu Mathew <tharindu at wso2.com>
>>> Imagine server X is going to be monitored by BAM and that X is going to
>>> send data to BAM by calling them right service published by BAM. The
>>> authn/authz needed is server to server auth - so what credential is used by
>>> X to call into BAM and how does BAM issue those to X?
>>> Here we use the pub sub model where bam acts as a subscriber and x acts
>>> as the publisher. When we are trying to subscribe to x through the broker
>>> client in BAM we need to have credentials with the relevant permission to
>>> initialize the client. Then to unsubscribe we need the same. After we
>>> subscribe we don't need any credentials since x just publishes the msg with
>>> a relevant topic to all the endpoints that have subscribed, which in this
>>> case would be BAM.
>> I realize this is the current model but IMO this is wrong. This model
>> assumes that all servers X that have interesting data for BAM to monitor
>> support WS-Eventing and can be subscribed to.
>> IMO the common case is the other way around - any server can be hacked up
>> to capture useful data and chuck it away somewhere. In our case that code
>> will call some BAM API method. To secure that we need to assign a credential
>> for each server so that it can safely call BAM services (or else BAM can be
>> taken down by a DoS attack) and X must have those creds somehow.
>> This is a standard server-to-server authentication/authorization problem
>> we have across our entire platform and we need to do it consistently across
>> the board! The two common choices are to issue a credential or to use
>> transport level mutual auth (symmetric SSL) and I think we support both in
>> most places (but I could be wrong).
> +1 for this model. I also agree this will be the more generic case. This way
> we can also remove the dependency on WS-Eventing and any bottlenecks (if
> any!) associated with it, while allowing external servers to submit data
> through an API.
>> Sanjiva Weerawarana, Ph.D.
>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/
>> email: sanjiva at wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 |
>> +1 650 265 8311
>> blog: http://sanjiva.weerawarana.org/
>> Lean . Enterprise . Middleware
> Tharindu Mathew
> Software Engineer,
> WSO2 Inc.,
Srinath Perera, Ph.D.
Senior Software Architect, WSO2 Inc.
Visiting Lecturer, University of Moratuwa
Member, Apache Software Foundation
Research Scientist, Lanka Software Foundation
More information about the Architecture