Hi, Going ahead, I am starting with the calculator service. Since we have our calculator service hosted as an rmi service, I have started to look into how security could be provided in an RMI Binding.
- Venkat On Nov 30, 2007 1:17 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > Hi, > > Heres what I am intending to do for the secure-bigbank into which I have > copied over the exiting calculator, stockquote and account demos into > secure-bigbank... > > - The Calculator and StockQuote services need to exchange data that cannot > be tampered with since the AccountService heavily 'relies' on their > results. So interaction with these two services should have 'integrity'. I > don't think there is a need for authentication or confidentiality for the > interactions with these services. > - The AccountData service is right now accessed only by the > AccountService. I'd like to open this out and put in the following security > constraints :- > - just keep authentication when accessed from the AccoutService > locally say over binding.sca > - enforce authentication, confidentiality and integrity when > accessed from outside say over binding.ws > - Finally the AccountService should enforce authentication, > confidentiality and integrity. > > Does this sound ok ? > > After an iteration with interaction policies, I'll start working on some > implementation policies. For example having 'authorization' enforced on the > AccountDataService's operations. > > Thanks > > - Venkat > > > > > > On Nov 30, 2007 1:41 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> > wrote: > > > Raymond Feng wrote: > > > Hi, > > > > > > I propose to add the following to the BigBank scenario too to cover > > > transaction policies and JMS binding. > > > > > > 1) Have separate components to represent the SavingsAccountService and > > > > > CheckingAccountService. The two services will be backed by two > > different > > > resource managers (Database or JMS queue). Please see the code at [1] > > > and diagrams at [2]. > > > > > > 2) Add a TransferService to transfer money between accounts. The > > > operations will be executed in a global transaction. > > > > > > 3) The TransferService will be exposed over binding.jms. The request > > of > > > money transfer from the web front will be served by the > > TransferService > > > over JMS. > > > > > > [1] > > > https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/transaction > > > > > > > > [2] > > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Transaction+Intents+and+Policies > > > > > > > > > > > Thanks, > > > Raymond > > > > > > > Sounds good to me. The other aspect that this scenario will allow us to > > explore is interaction between the JMS binding and databindings (as > > Bigbank flows complex types). > > > > I'd suggest to work on these two versions of Bigbank in parallel in > > different modules: > > a) secure bigbank with security policies > > b) reliable transfers with JMS and transactions > > i.e. two different copies of BigBank. > > > > And then bring the two together at some point later. > > -- > > Jean-Sebastien > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
