Hi, So to summarize what's been done upto now - the interactions between Bigbank and StockQuote have been enabled for integrity. The Bigbank's dependency on the AccountsDataService has been changed from a inner composite implementation to a binding.ws reference and then this interaction has been enable for authentication. Here is a summary of my observations upto now....
- In this demo I've had to define two definitions.xml one for the bigbank application and another for the stock quote application. Each of these files has a bunch of standard sca intents that had to be copied over. Maybe we could define the standard ones elsewhere and allow the app.developer or policy admin to assume that these intents will be made available by the SCA runtime itself. - Assume there are two instances of a binding.ws and that they both specified 'authentication'. However the policyset to be applied each of them is different say policySetOne and policySetTwo then there is currently no way of making sure that when the matching policysets are worked out it these two instances get assigned the right policySet. The only way of getting this done is by specifying the policySet itself in the binding.wsdeclaration in the composite. An alternative might be to use the 'appliesTo' xpath attribute of the PolicySet to include the binding uri so that only a policyset that must apply to a binding instance gets matched. I faced this issue with the Bigbank and AccoutsData services both specifying authentication but needed different policyset as one was a client and another was a server. - I did not have to do anything with policy-handlers since I was working only with binding.ws where policy handling code was already in place. Also we had decided not to parallely go about enabling the extensions for policy handling. Do others have additional observations about the policy fwk ? Any other thoughts ? Thanks - Venkat On Dec 3, 2007 9:12 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > 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] > > > > > > > > > > > > > >
