Hi Sebastien, Thanks for taking a look and thinking about this. Please find my answers inline.
- Venkat On Dec 14, 2007 3:36 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Venkata Krishnan 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 > > > > I took a look at secure-bigbank. It's a good start which helps > understand how to use the policy framework, and triggers some questions: > > - The accountDataService reference is bound to 8084, while the > AccountDataService is bound to 8085? aren't they supposed to be wired > together? Sorry, that's a bug. I was using the TCPMonitor to intercept client-server communications for a bit of debugging. This monitor was listening on 8084 on one side and forwarding the packets to 8085. I'll fix that. > - Why did you need two authentication and wsAuthentication intents? is > it because you needed different policy sets on the client and service > side? > Yes, that's the reason. Since the policysets encapsulate things like the username, password callback hander etc. which could be different for the client and the server there needed to be different policysets. Having the same intent does no guarantee that the right policyset will be matched i.e. the client's policyset for the reference and the server's policyset for the service. Having unique intents will ensure this mapping. > > - Did you have to change the WS binding code to support your new user > defined wsAuthentication intent? > No. Just to clarify, the mapping of policysets to intents is done by the core runtime. Now, how a policyset or what is mentioned in it needs to be affected is what is done in the binding code. So the wsBinding knows to what is to be done with wsConfigParam based PolicySets and WS-Policy based PolicySets to enable security. > > - Is there a way to not repeat the core intents defined by the spec in > all contributions? No. This is one of the concerns I have and could be resolved by having multiple definitions.xml files. Also the various artifacts in a composite would like to enforce a particular intent say 'authentication' in their own respective ways for which there may be appropriate policysets defined. Mapping authentication to different policysets for different artifacts is not possible. Am not sure if the specs meant that all artifacts should use just about one type of realization of an intent. > > > - Where are the bindingType definitions listing the intents provided by > the bindings? I had deliberately kept this out of this scenario to help us arrive at its usage. The 'constrains' attribute of Intents is what is being used to figure out the intents supported by the bindingType or ImplType. Now as I am writing this I see that a right way to see if an intent is supported on a bindingtype or implTyp is to check against the BindingType or ImplementationType definitions. This also leads me to think that for every intent 'mayProvided' by a bindingType there is just one mapping policyset that will be used. > > - What are the security callback handlers responsible for? > Until I looked at JAAS yesterday, I thought they are the hooks that the bindings will call to enable applications to go off into user registries and perform authentication. Looking at JAAS it seems like the callback handlers are typically used to 'fetch' the username and password. There is a LoginModule that actually encapsulates how and against what sort of user registry these things are authenticated and its the LoginModule that calls these handlers to simply fetch the user or client inputs. I must dig up Rampart to see if this is what it also intends. > > Thanks > -- > Jean-Sebastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
