Hi, Any further modifications to this demo will require additions to our binding extensions to handle policies. Since this is something that we'd prefer not to do in patches I have made the AccountsDataService to use binding.ws and have enforced 'authentication'.
The Bigbank application must now authenticate itself with the AccountsDataService to obtain accounts data. The Bigbank and the AccountsDataService have a 'password callback handler' (think of it as a hook) implemented where they work out means of setting and retrieving userids and passwords to be used for this authentication. Since we need two policysets one for the server side (AccoutsData) and another for the client side(Bigbank) I've had to create two intents 'authentication' and 'wsAuthentication' so that these different policysets match. If it had been just 'authenticatoin' for both client and server there is no criteria that we can use to match to the server side or client side policy set appropriately. Thanks - Venkat On Dec 1, 2007 9:12 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > Hi, > > I have now committed a first cut of the secure-bigbank demo under > r600142. Sorry couldn't do this yesterday itself as I was not doing well. > > For now I have enabled the StockQuote webservice for 'integrity'... > - First to be able to enforce 'integrity' the Bigbank and StockQuote > applications define the integrity intent and the policyset that would > realize this intent, in each of thier definitions.xml file > - Since integrity involves signing of the soap messages the Bigbank and > StockQuote setup their keystores. They decide on their individual user ids > whose key would be used for the signing. > - Each of them then imports the other's key into its keystore so that when > message are exchanged between the two the signatures can be verified. > - Since Rampart is the module that is going to facilitate integrity, the > Bigbank and StockQuote forumlate policysets that encapsulate the necessary > inputs for Rampart to enforce integrity. Typically the policyset includes > details related to the keystore and the userid used for signing. > - Then the Bigbank marks the 'stockQuote reference' as requiring integrity > and the StockQuote marks the 'stockQuote service' as requiring integrity > - The Bigbank and the StockQuote implement a PassworkCallBackHandler class > from where they manage the userid and passwords. For example when a message > is to be signed Rampart would like to retrieve the key to be used for such > signing from the keystore. To retrieve this key, a userid and password is > required. While the userid to be used is picked up from the policyset, the > password for this userid is obtained from te PasswordCallBackHandler. > > When you run this demo, you'd notice some prints that I have included in > the PasswordCallbackHandler being displayed in the bigbank-accound and > stockquote consoles. This is just for time being to ensure that the > PasswordCallBankHanlder is looped in and also to verify the userids that are > being used for the signing. > > Thanks > > - Venkat > > > On Dec 1, 2007 3:47 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > > Thanks and point taken :). I am also comfortable with tinkering the > > runtime and extensions to make this scenario work. I'd rather take note of > > the gaps and discuss them to resolution in a wholistic manner. > > > > - Venkat > > > > > > On Nov 30, 2007 11:50 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > > > I suggest that we not expand too quickly into other bindings such as > > > RMI. > > > Let's focus on getting your previous proposal (StockQuote, AccountData > > > services) implemented first. > > > > > > Thanks, > > > Raymond > > > > > > ----- Original Message ----- > > > From: "Venkata Krishnan" <[EMAIL PROTECTED]> > > > To: < [EMAIL PROTECTED]> > > > Sent: Friday, November 30, 2007 7:41 AM > > > Subject: Re: Using security policies in the Bigbank scenario, was Re: > > > Policy > > > Framework Scenarios. > > > > > > > > > > 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] > > > >> > > > > >> > > > > >> > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > >
