[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Private or local channels
>We're back into really squish security territory. As soon as you open >up a network connection, the activity might be "visible" to outside >parties. I'm certain that we have to leave it up to implementations of >SCA, and the assemblers of composities as to how rigorously they work >to prevent exposure to the contents of messages, and likewise, how >rigorously they work to prevent "outside" messages from being >processed. In the end, it *can* be compromised, the relevant security >question is whether it is the weakest link, or not. I think this is the key in looking at this issue. And not unlike how we have dealt with things like WS binding on a service. Once you deploy a service, the SCA spec cannot/should not guarantee/prevent who is going to connect to that network endpoint. I should also clarify what I meant in my earlier comment: "I agree that the events cannot be visible to *SCA* components outside that composite, in that SCA domain. But I think our disagreement is wrt visibility to non-SCA things." I meant to say that we model channels in the composite and we can talk about channel visibility. IOW, what is (or isn't) available for use wrt the value specified on the target/source attribute of producer/consumer. In that regard, for components that are outside a composite C, do not have visibility to the local channels declared in composite C. Now whether they have visibility to the events in channel C, depends on the implementation/deployment. For example, the spec does not restrict two channels A and B that are local channels in composite X and Y, respectively, being mapped to the "same thing" underneath by an implementation. And I don't think we should prevent it in the spec. It should be left as an implementation/assembler/deployer choice. -Anish -- On 2/3/2011 9:47 AM, Eric Johnson wrote: > Hi Anish, Peter, > > On 2/3/11 7:24 AM, Anish Karmarkar wrote: >> On 2/1/2011 8:02 AM, Peter Niblett wrote: >>> I still see a requirement for scoping the exchange of events so that it >>> stays encapsulated within a composite. >> >> I agree that the events cannot be visible to *SCA* components outside >> that composite, in that SCA domain. But I think our disagreement is >> wrt visibility to non-SCA things. > > We're back into really squish security territory. As soon as you open up > a network connection, the activity might be "visible" to outside > parties. I'm certain that we have to leave it up to implementations of > SCA, and the assemblers of composities as to how rigorously they work to > prevent exposure to the contents of messages, and likewise, how > rigorously they work to prevent "outside" messages from being processed. > In the end, it *can* be compromised, the relevant security question is > whether it is the weakest link, or not. > >> Why is it necessary to restrict the visibility to, say, a monitoring >> application that wants to provide a console to the admin? > > Yes, as Anish points out, the fact that the messages might be visible > outside SCA's confines might be a feature of some implementations, not a > bug. > >> >>> It has hard to develop and test >>> such a composite if there's a risk that its internal components can get >>> bombarded with events from who knows where once it is deployed. That was >>> my understanding for why we had private channels in the first place. >>> >> >> I don't see why this is hard to develop or test. > > I agree with Anish on this - if an SCA runtime uses its own JMS > deployment, and we do testing via a domain contribution just > contributed, I don't see how it is that some *other* non-SCA application > is going to show up and start bombarding the SCA consumers with > unexpected messages. If they do, your network has been compromised, and > that probably invalidates the tests anyway. > >> It is still under your control as to who gets visibility. Either >> because you are in control of deployment of even non-SCA things or >> through the use of some security mechanism. >> WRT testing, why would you care who else sees the events, or even who >> else sends additional events. I would think that for our testing we >> would just have to make sure that all events that were sent by SCA >> components are delivered to all the consumers with the 'right' >> filters/connections. >> >>> There are other ways in which you can reference a genuine external JMS >>> topic >>> >>> 1. Reference a global channel bound to the JMS topic (global channels >>> seem a much better fit for something that is external to the whole >>> assembly) >> >> I tend to agree with this. But I don't want to mandate it. > > As I think I've said on the call, that actually seems backwards to me. > Binding to an existing JMS Topic seems like something you want to do in > a very local manner, where you start migrating an existing application > that uses JMS into the SCA world, and you do it piecemeal. You're not > likely to want to expose a *global* domain channel bound to that topic, > because that would affect the existing external application. > > -Eric. > >> >>> 2. Bind the producer or consumer directly to the JMS topic >> >> We don't allow that in the current draft. >> >>> 3. Promote the producer or consumer to the composite level, and bind >>> that to the JMS topic. >>> >> >> We don't allow that in the current draft, but of course this is >> another issue that has been filed. >> >>> Of course I could get the functionality I want from private channels in >>> another way if I were allowed to wire producers directly to consumers. >>> >>> Peter Niblett >>> IBM Senior Technical Staff Member >>> Member of the IBM Academy of Technology >>> +44 1962 815055 >>> +44 7825 657662 (mobile) >>> >>> >>> >>> >>> From: Anish Karmarkar <Anish.Karmarkar@oracle.com> >>> To: OASIS Assembly <sca-assembly@lists.oasis-open.org> >>> Date: 01/02/2011 15:02 >>> Subject: [sca-assembly] Private or local channels >>> ------------------------------------------------------------------------ >>> >>> >>> >>> During last week's call Peter and I had a little bit of back on forth in >>> the chat regarding private/local channels. I would like to start a >>> discussion on it on the ML before I file an issue (or not, depending on >>> the outcome of the discussion). >>> >>> Peter has pointed out that line 2815 of our spec says: >>> >>> "Channels within a composite used as an implementation are private to >>> the components within that composite. These private channels can only be >>> the targets for producers existing within the same composite as the >>> channel. Private channels can only be sources for consumers existing >>> withing the same composite as the channel. An SCA runtime MAY support >>> the use of private channels " >>> >>> Peter's interpretation of this is that composite channels are not >>> visible to components outside the composite *and* to anyone outside of >>> the SCA-world. I have a different interpretation of this. I don't think >>> our spec should talk about what things outside of SCA do or don't do. We >>> should allow for enough freedom wrt the technology use to implement the >>> channels. It could be an in-memory channel that is true invisible to >>> anyone outside the process or a JMS topic, which would have visibility >>> outside of SCA. We currently allow bindings on a composite channel; that >>> to me indicates that we intended to allow such variability. If folks >>> agree with my interpretation, I think we should change the wordings to >>> replace 'private' with 'local', so as not the give an incorrect >>> impression. >>> >>> Comments? >>> >>> -Anish >>> -- >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this mail list, you must leave the OASIS TC that >>> generates this mail. Follow this link to all your TCs in OASIS at: >>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> / >>> / >>> >>> /Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>> PO6 3AU/ >>> >>> >>> >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]