Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Hi Sebastien, am working on this and should be done today. Am just about taking a bit of time to fit this into our existing ContributionService implementation. - Venkat On Feb 6, 2008 12:49 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Ok, let me go try this and post back. I'd like to vary this a bit - but let me have some code to talk about. Meanwhile, I did get ahead with my proposal but did not quite like the way I had to pass the CompositeProcessor all the way from the Runtime down to the builders. It seemed very hacky. - Venkat On Feb 6, 2008 5:54 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Reading the composite file / building its model / re-writing it to finally apply the xpath sounds very complicated. As an application developer I'll write the appliesTo xpath to match what I see in a composite XML file. Why can't we simply run the xpath on that original XML file before doing all the other steps? Venkata Krishnan wrote: We will not be writing the entire composite, but only a fragment that is the parent of the intentAttachPoint. Here is what the spec says : - 283 ..Note that the XPath expression will always be evaluated 284 within the context of an attachment considering elements where binding instances or 285 implementations are allowed to be present. The expression is evaluated against the parent element 286 of any binding or implementation element. .. But then, it seems like we may have to look beyond the immediate parent or maybe the entire composite if your proposal is to be taken. Yes, but it's not incompatible. Here are some examples: appliesTo=binding.ws appliesTo=[EMAIL PROTECTED]'AccountService'] appliesTo=../[EMAIL PROTECTED]'AccountServiceComponent'] appliesTo=/[EMAIL PROTECTED]'bigbank']/[EMAIL PROTECTED]'AccountServiceComponent'] By default you are in the parent of a binding or implementation, but can use .. or / to go up. I'd like to hear some perspectives from the specs folks on this. Now, getting to your question more specifically on why this must be done post-build phase, here it is - Firstly we need the PolicySet definitions to get hold of the 'appliesTo'. - For PolicySets that are specified in the composite, they are resolved during the resolution phase. - For those that have to be calculated based on the Intents specified, there needs to be a complete assembly model that is wired, since we also need to take into account the target's intents. This wiring is being done on the 'wireComposite' method of the CompositeWireBuilder. - So the calculation of PolicySets is pushed to this point i.e. its being done as part of the 'wireComposite' method, the moment the model has all its connections resolved. - Only after the PolicySets are calculated, do we have a handle on the 'appliesTo' attribute of the PolicySets. How about this: load the definitions.xml files declaring policySets. for each policyset prepend /*/*/ to its appliesTo xpath for each composite XML file run the xpath expression against the file for each matching element add the policySet to an imaginary applicablePolicySets attribute end end end Then later when you run the composite processors, builders etc, use the intents + policySets + applicablePolicySets attributes to figure the effective policySets. This should provide the best of both worlds: - xpath expressions evaluated against the real authored XML artifacts - support for the intent/policySet matching algorithm from the spec Makes sense? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Venkata Krishnan wrote: From the history of this mail, I suspect that you haven't got my post in http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27575.html. I am certainly eager to fix this. Let me know your thoughts on what I have asked there. Thanks. Sorry, it's weird, I never received your post. Venkata Krishnan wrote: The only issue standing in the way is of how we get hold of the SCDL over which the xpath in 'appliesTo' can be applied. I'd like to use our assembly model writers to write back an SCA artifact (component or service ... ) as XML and then apply the xpath in appliesTo over this XML. All this must be done in the policyset matching phase. Reading the composite file / building its model / re-writing it to finally apply the xpath sounds very complicated. As an application developer I'll write the appliesTo xpath to match what I see in a composite XML file. Why can't we simply run the xpath on that original XML file before doing all the other steps? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
On Feb 5, 2008 2:38 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: From the history of this mail, I suspect that you haven't got my post in http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27575.html. I am certainly eager to fix this. Let me know your thoughts on what I have asked there. Thanks. Sorry, it's weird, I never received your post. Venkata Krishnan wrote: The only issue standing in the way is of how we get hold of the SCDL over which the xpath in 'appliesTo' can be applied. I'd like to use our assembly model writers to write back an SCA artifact (component or service ... ) as XML and then apply the xpath in appliesTo over this XML. All this must be done in the policyset matching phase. Reading the composite file / building its model / re-writing it to finally apply the xpath sounds very complicated. As an application developer I'll write the appliesTo xpath to match what I see in a composite XML file. Why can't we simply run the xpath on that original XML file before doing all the other steps? We will not be writing the entire composite, but only a fragment that is the parent of the intentAttachPoint. Here is what the spec says : - 283 ..Note that the XPath expression will always be evaluated 284 within the context of an attachment considering elements where binding instances or 285 implementations are allowed to be present. The expression is evaluated against the parent element 286 of any binding or implementation element. .. But then, it seems like we may have to look beyond the immediate parent or maybe the entire composite if your proposal is to be taken. I'd like to hear some perspectives from the specs folks on this. Now, getting to your question more specifically on why this must be done post-build phase, here it is - Firstly we need the PolicySet definitions to get hold of the 'appliesTo'. - For PolicySets that are specified in the composite, they are resolved during the resolution phase. - For those that have to be calculated based on the Intents specified, there needs to be a complete assembly model that is wired, since we also need to take into account the target's intents. This wiring is being done on the 'wireComposite' method of the CompositeWireBuilder. - So the calculation of PolicySets is pushed to this point i.e. its being done as part of the 'wireComposite' method, the moment the model has all its connections resolved. - Only after the PolicySets are calculated, do we have a handle on the 'appliesTo' attribute of the PolicySets. Let me know if you like me to explain a little more. Thanks - Venkat -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
.. meanwhile... I have started to make some changes locally to see if what I am proposing about pulling the builder into a module and using the wirters to write relevant fragments of SCDL, is feasible... - Venkat On Feb 5, 2008 3:52 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: On Feb 5, 2008 2:38 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: From the history of this mail, I suspect that you haven't got my post in http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27575.html. I am certainly eager to fix this. Let me know your thoughts on what I have asked there. Thanks. Sorry, it's weird, I never received your post. Venkata Krishnan wrote: The only issue standing in the way is of how we get hold of the SCDL over which the xpath in 'appliesTo' can be applied. I'd like to use our assembly model writers to write back an SCA artifact (component or service ... ) as XML and then apply the xpath in appliesTo over this XML. All this must be done in the policyset matching phase. Reading the composite file / building its model / re-writing it to finally apply the xpath sounds very complicated. As an application developer I'll write the appliesTo xpath to match what I see in a composite XML file. Why can't we simply run the xpath on that original XML file before doing all the other steps? We will not be writing the entire composite, but only a fragment that is the parent of the intentAttachPoint. Here is what the spec says : - 283 ..Note that the XPath expression will always be evaluated 284 within the context of an attachment considering elements where binding instances or 285 implementations are allowed to be present. The expression is evaluated against the parent element 286 of any binding or implementation element. .. But then, it seems like we may have to look beyond the immediate parent or maybe the entire composite if your proposal is to be taken. I'd like to hear some perspectives from the specs folks on this. Now, getting to your question more specifically on why this must be done post-build phase, here it is - Firstly we need the PolicySet definitions to get hold of the 'appliesTo'. - For PolicySets that are specified in the composite, they are resolved during the resolution phase. - For those that have to be calculated based on the Intents specified, there needs to be a complete assembly model that is wired, since we also need to take into account the target's intents. This wiring is being done on the 'wireComposite' method of the CompositeWireBuilder. - So the calculation of PolicySets is pushed to this point i.e. its being done as part of the 'wireComposite' method, the moment the model has all its connections resolved. - Only after the PolicySets are calculated, do we have a handle on the 'appliesTo' attribute of the PolicySets. Let me know if you like me to explain a little more. Thanks - Venkat -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Jean-Sebastien Delfino wrote: Reading the composite file / building its model / re-writing it to finally apply the xpath sounds very complicated. As an application developer I'll write the appliesTo xpath to match what I see in a composite XML file. Why can't we simply run the xpath on that original XML file before doing all the other steps? Venkata Krishnan wrote: We will not be writing the entire composite, but only a fragment that is the parent of the intentAttachPoint. Here is what the spec says : - 283 ..Note that the XPath expression will always be evaluated 284 within the context of an attachment considering elements where binding instances or 285 implementations are allowed to be present. The expression is evaluated against the parent element 286 of any binding or implementation element. .. But then, it seems like we may have to look beyond the immediate parent or maybe the entire composite if your proposal is to be taken. Yes, but it's not incompatible. Here are some examples: appliesTo=binding.ws appliesTo=[EMAIL PROTECTED]'AccountService'] appliesTo=../[EMAIL PROTECTED]'AccountServiceComponent'] appliesTo=/[EMAIL PROTECTED]'bigbank']/[EMAIL PROTECTED]'AccountServiceComponent'] By default you are in the parent of a binding or implementation, but can use .. or / to go up. I'd like to hear some perspectives from the specs folks on this. Now, getting to your question more specifically on why this must be done post-build phase, here it is - Firstly we need the PolicySet definitions to get hold of the 'appliesTo'. - For PolicySets that are specified in the composite, they are resolved during the resolution phase. - For those that have to be calculated based on the Intents specified, there needs to be a complete assembly model that is wired, since we also need to take into account the target's intents. This wiring is being done on the 'wireComposite' method of the CompositeWireBuilder. - So the calculation of PolicySets is pushed to this point i.e. its being done as part of the 'wireComposite' method, the moment the model has all its connections resolved. - Only after the PolicySets are calculated, do we have a handle on the 'appliesTo' attribute of the PolicySets. How about this: load the definitions.xml files declaring policySets. for each policyset prepend /*/*/ to its appliesTo xpath for each composite XML file run the xpath expression against the file for each matching element add the policySet to an imaginary applicablePolicySets attribute end end end Then later when you run the composite processors, builders etc, use the intents + policySets + applicablePolicySets attributes to figure the effective policySets. This should provide the best of both worlds: - xpath expressions evaluated against the real authored XML artifacts - support for the intent/policySet matching algorithm from the spec Makes sense? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Ok, let me go try this and post back. I'd like to vary this a bit - but let me have some code to talk about. Meanwhile, I did get ahead with my proposal but did not quite like the way I had to pass the CompositeProcessor all the way from the Runtime down to the builders. It seemed very hacky. - Venkat On Feb 6, 2008 5:54 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Reading the composite file / building its model / re-writing it to finally apply the xpath sounds very complicated. As an application developer I'll write the appliesTo xpath to match what I see in a composite XML file. Why can't we simply run the xpath on that original XML file before doing all the other steps? Venkata Krishnan wrote: We will not be writing the entire composite, but only a fragment that is the parent of the intentAttachPoint. Here is what the spec says : - 283 ..Note that the XPath expression will always be evaluated 284 within the context of an attachment considering elements where binding instances or 285 implementations are allowed to be present. The expression is evaluated against the parent element 286 of any binding or implementation element. .. But then, it seems like we may have to look beyond the immediate parent or maybe the entire composite if your proposal is to be taken. Yes, but it's not incompatible. Here are some examples: appliesTo=binding.ws appliesTo=[EMAIL PROTECTED]'AccountService'] appliesTo=../[EMAIL PROTECTED]'AccountServiceComponent'] appliesTo=/[EMAIL PROTECTED]'bigbank']/[EMAIL PROTECTED]'AccountServiceComponent'] By default you are in the parent of a binding or implementation, but can use .. or / to go up. I'd like to hear some perspectives from the specs folks on this. Now, getting to your question more specifically on why this must be done post-build phase, here it is - Firstly we need the PolicySet definitions to get hold of the 'appliesTo'. - For PolicySets that are specified in the composite, they are resolved during the resolution phase. - For those that have to be calculated based on the Intents specified, there needs to be a complete assembly model that is wired, since we also need to take into account the target's intents. This wiring is being done on the 'wireComposite' method of the CompositeWireBuilder. - So the calculation of PolicySets is pushed to this point i.e. its being done as part of the 'wireComposite' method, the moment the model has all its connections resolved. - Only after the PolicySets are calculated, do we have a handle on the 'appliesTo' attribute of the PolicySets. How about this: load the definitions.xml files declaring policySets. for each policyset prepend /*/*/ to its appliesTo xpath for each composite XML file run the xpath expression against the file for each matching element add the policySet to an imaginary applicablePolicySets attribute end end end Then later when you run the composite processors, builders etc, use the intents + policySets + applicablePolicySets attributes to figure the effective policySets. This should provide the best of both worlds: - xpath expressions evaluated against the real authored XML artifacts - support for the intent/policySet matching algorithm from the spec Makes sense? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Hi Sebastien, From the history of this mail, I suspect that you haven't got my post in http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27575.html. I am certainly eager to fix this. Let me know your thoughts on what I have asked there. Thanks. On Feb 3, 2008 12:50 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Venkata Krishnan wrote: - 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. After looking at this again today I think that having different custom authentication intents defeats the purpose of intents, turning them into disguised policySets as they become specific to the particular config of authentication in parts of your network. We need a different approach: - keep intents abstract (authentication) - declare where different policySets providing authentication should be applied in the composition. PolicySet/appliesTo already provides a way to scope the application of a policySet. Can we just use that? Some examples: appliesTo=binding.ws appliesTo=[EMAIL PROTECTED]'AccountService'] appliesTo=../[EMAIL PROTECTED]'AccountServiceComponent'] Thoughts? Following up as nobody has posted any further thoughts. Is the above proposal clear? Does anybody want to try to fix the policy story or do you want me to do it? Also, in my opinion having two bigbank samples is overkill. I think we should just add the policy configuration to the original bigbank instead of having a secure-bigbank duplicating bigbank. Any objections? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Jean-Sebastien Delfino wrote: Venkata Krishnan wrote: - 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. After looking at this again today I think that having different custom authentication intents defeats the purpose of intents, turning them into disguised policySets as they become specific to the particular config of authentication in parts of your network. We need a different approach: - keep intents abstract (authentication) - declare where different policySets providing authentication should be applied in the composition. PolicySet/appliesTo already provides a way to scope the application of a policySet. Can we just use that? Some examples: appliesTo=binding.ws appliesTo=[EMAIL PROTECTED]'AccountService'] appliesTo=../[EMAIL PROTECTED]'AccountServiceComponent'] Thoughts? Following up as nobody has posted any further thoughts. Is the above proposal clear? Does anybody want to try to fix the policy story or do you want me to do it? Also, in my opinion having two bigbank samples is overkill. I think we should just add the policy configuration to the original bigbank instead of having a secure-bigbank duplicating bigbank. Any objections? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Hi, I agree to your views on intents and I also like the proposal you are making with respect to making use of 'appliesTo'. Sounds like a clean way out. The only issue standing in the way is of how we get hold of the SCDL over which the xpath in 'appliesTo' can be applied. I'd like to use our assembly model writers to write back an SCA artifact (component or service ... ) as XML and then apply the xpath in appliesTo over this XML. All this must be done in the policyset matching phase. However, matching of policysets happen in the Builders which is in the assembly module and referring back to the assembly-xml for the writers causes a cyclic dependency. Will moving the builders out to a separate module like assembly-builder be a good way out. Or, is there any other better way of getting hold of the SCDL or accessing the assembly model writers ? Thanks - Venkat On Jan 25, 2008 9:52 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: - 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. After looking at this again today I think that having different custom authentication intents defeats the purpose of intents, turning them into disguised policySets as they become specific to the particular config of authentication in parts of your network. We need a different approach: - keep intents abstract (authentication) - declare where different policySets providing authentication should be applied in the composition. PolicySet/appliesTo already provides a way to scope the application of a policySet. Can we just use that? Some examples: appliesTo=binding.ws appliesTo=[EMAIL PROTECTED]'AccountService'] appliesTo=../[EMAIL PROTECTED]'AccountServiceComponent'] Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Venkata Krishnan wrote: - 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. After looking at this again today I think that having different custom authentication intents defeats the purpose of intents, turning them into disguised policySets as they become specific to the particular config of authentication in parts of your network. We need a different approach: - keep intents abstract (authentication) - declare where different policySets providing authentication should be applied in the composition. PolicySet/appliesTo already provides a way to scope the application of a policySet. Can we just use that? Some examples: appliesTo=binding.ws appliesTo=[EMAIL PROTECTED]'AccountService'] appliesTo=../[EMAIL PROTECTED]'AccountServiceComponent'] Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Hi, I have changed this now to put the computed intents back into the binding/implementation instance. So the bindings and implementations can now parse the intents and filter the mayProvided ones and take appropriate actions. I'm trying to see if I can get this demonstrated on our axis2 binding. I've also made some changes to now get the bindingType and implementationType definitions in order. Here is how things should work from now on : - - every binding and implementation type has a definitions.xml file in the META-INF/services directory in which will be defined a bindingType or implementationType element that contains all the intents mayProvided and alwaysProvided by the binding / implementation type. - ever binding / implementation instance will have reference to this corresponding type bindingType or implementationType definition. All this under r614447. Thanks - Venkat On Jan 16, 2008 12:52 AM, Greg Dritschler [EMAIL PROTECTED] wrote: I agree that intents that are listed in mayProvide do not require a policy set. The binding/implementation provides the functionality of the intent if the intent is present on the relevant composite element. It looks to me that CompositeWireBuilderImpl, as part of the process of trying to find matching policy sets, removes intents that are found in mayProvide from the model object. In that case, how would the binding/implementation know it should provide the intent functionality if the intent isn't present in the model anymore? Greg Dritschler
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
I agree that intents that are listed in mayProvide do not require a policy set. The binding/implementation provides the functionality of the intent if the intent is present on the relevant composite element. It looks to me that CompositeWireBuilderImpl, as part of the process of trying to find matching policy sets, removes intents that are found in mayProvide from the model object. In that case, how would the binding/implementation know it should provide the intent functionality if the intent isn't present in the model anymore? Greg Dritschler
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Hi, I have now changed things to allow for multiple definitions.xml file. The contents of the various definitions.xml file for a domain are all aggregated. The runtime and extensions can contribute sca definitions with a definitions.xml in the META-INF/services directory while contributions can also have their definitions.xml as any other artifact. With this contributions need not redefine the intents supported by the Tuscany runtime and can assume them to be available to them. Thanks - Venkat On Dec 26, 2007 4:56 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Sebastien, Please find my comments inline. Thanks. - Venkat On Dec 15, 2007 2:52 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: - 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. I'm not getting it sorry :) Why are the wired reference and target service policysets different? If they are different how do you validate that wiring the reference to the service is allowed? First, the comparison of policysets is dependent on the mechanisms supported by the policies that they embed. For example WS-Policy has prescribed mechanism to calculate intersection of two policy instances to see if they are compatible or match. So the policysets could be different on either sides, but the policies embedded within need to compatible. Having said that, the policysets on the target is available for locally wired services. For services that are in a different runtime, I suppose the service interfaces must publish this information for example as some extensions to the wsdl. This is something that need further study and exploration. - 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. Good - 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. OK, here are some suggestions to improve that: To allow an admin to configure policies on a domain basis and on a contribution basis: - Package Definitions.xml files in SCA contributions contributed to the domain. - Assume that definitions in the SCA namespace are available in the whole domain. - Import definitions from user namespaces using the standard SCA XML import mechanism. To describe the capabilities of binding and implementation runtimes: - Package a definitions.xml file in their JARs - Containing relevant bindingType and implementationType definitions. Thanks :). I'll work on this. Infact for a first cut I could just about see if I can aggregate definitions.xml in a way similar to our service configuration files. We should ask the policy spec folks how they envision definitions.xml being authored and used. 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. Not sure, that's a good question for the spec folks. - 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. My understanding was different: - if alwaysProvided - the binding always assumes that the intent is set - if mayProvide - you can set the intent without specifying a policySet - else, you are allowed to set the intent on a binding if there is a policyset that says provides = that intent and appliesTo = that binding. This also leads me to think that for every intent 'mayProvided' by a bindingType there
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Wonderful, thats really good! ..ant On Jan 3, 2008 4:41 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I have now changed things to allow for multiple definitions.xml file. The contents of the various definitions.xml file for a domain are all aggregated. The runtime and extensions can contribute sca definitions with a definitions.xml in the META-INF/services directory while contributions can also have their definitions.xml as any other artifact. With this contributions need not redefine the intents supported by the Tuscany runtime and can assume them to be available to them. Thanks - Venkat On Dec 26, 2007 4:56 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Sebastien, Please find my comments inline. Thanks. - Venkat On Dec 15, 2007 2:52 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: - 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. I'm not getting it sorry :) Why are the wired reference and target service policysets different? If they are different how do you validate that wiring the reference to the service is allowed? First, the comparison of policysets is dependent on the mechanisms supported by the policies that they embed. For example WS-Policy has prescribed mechanism to calculate intersection of two policy instances to see if they are compatible or match. So the policysets could be different on either sides, but the policies embedded within need to compatible. Having said that, the policysets on the target is available for locally wired services. For services that are in a different runtime, I suppose the service interfaces must publish this information for example as some extensions to the wsdl. This is something that need further study and exploration. - 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. Good - 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. OK, here are some suggestions to improve that: To allow an admin to configure policies on a domain basis and on a contribution basis: - Package Definitions.xml files in SCA contributions contributed to the domain. - Assume that definitions in the SCA namespace are available in the whole domain. - Import definitions from user namespaces using the standard SCA XML import mechanism. To describe the capabilities of binding and implementation runtimes: - Package a definitions.xml file in their JARs - Containing relevant bindingType and implementationType definitions. Thanks :). I'll work on this. Infact for a first cut I could just about see if I can aggregate definitions.xml in a way similar to our service configuration files. We should ask the policy spec folks how they envision definitions.xml being authored and used. 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. Not sure, that's a good question for the spec folks. - 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. My understanding was different: - if alwaysProvided - the binding always assumes that the intent is set - if mayProvide - you can set the intent
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Hi Sebastien, Please find my comments inline. Thanks. - Venkat On Dec 15, 2007 2:52 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: - 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. I'm not getting it sorry :) Why are the wired reference and target service policysets different? If they are different how do you validate that wiring the reference to the service is allowed? First, the comparison of policysets is dependent on the mechanisms supported by the policies that they embed. For example WS-Policy has prescribed mechanism to calculate intersection of two policy instances to see if they are compatible or match. So the policysets could be different on either sides, but the policies embedded within need to compatible. Having said that, the policysets on the target is available for locally wired services. For services that are in a different runtime, I suppose the service interfaces must publish this information for example as some extensions to the wsdl. This is something that need further study and exploration. - 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. Good - 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. OK, here are some suggestions to improve that: To allow an admin to configure policies on a domain basis and on a contribution basis: - Package Definitions.xml files in SCA contributions contributed to the domain. - Assume that definitions in the SCA namespace are available in the whole domain. - Import definitions from user namespaces using the standard SCA XML import mechanism. To describe the capabilities of binding and implementation runtimes: - Package a definitions.xml file in their JARs - Containing relevant bindingType and implementationType definitions. Thanks :). I'll work on this. Infact for a first cut I could just about see if I can aggregate definitions.xml in a way similar to our service configuration files. We should ask the policy spec folks how they envision definitions.xml being authored and used. 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. Not sure, that's a good question for the spec folks. - 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. My understanding was different: - if alwaysProvided - the binding always assumes that the intent is set - if mayProvide - you can set the intent without specifying a policySet - else, you are allowed to set the intent on a binding if there is a policyset that says provides = that intent and appliesTo = that binding. This also leads me to think that for every intent 'mayProvided' by a bindingType there is just one mapping policyset that will be used. I thought that mayProvide didn't require a policyset. I may have mis-understood, that's another question for the spec folks. I think your interpretation is convincing. So I'll go an change the policyset resolution codes to skip looking for policysets if an intent is found either in the alwaysProvided or mayProvided list. - 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
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Venkata Krishnan wrote: - 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. I'm not getting it sorry :) Why are the wired reference and target service policysets different? If they are different how do you validate that wiring the reference to the service is allowed? - 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. Good - 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. OK, here are some suggestions to improve that: To allow an admin to configure policies on a domain basis and on a contribution basis: - Package Definitions.xml files in SCA contributions contributed to the domain. - Assume that definitions in the SCA namespace are available in the whole domain. - Import definitions from user namespaces using the standard SCA XML import mechanism. To describe the capabilities of binding and implementation runtimes: - Package a definitions.xml file in their JARs - Containing relevant bindingType and implementationType definitions. We should ask the policy spec folks how they envision definitions.xml being authored and used. 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. Not sure, that's a good question for the spec folks. - 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. My understanding was different: - if alwaysProvided - the binding always assumes that the intent is set - if mayProvide - you can set the intent without specifying a policySet - else, you are allowed to set the intent on a binding if there is a policyset that says provides = that intent and appliesTo = that binding. This also leads me to think that for every intent 'mayProvided' by a bindingType there is just one mapping policyset that will be used. I thought that mayProvide didn't require a policyset. I may have mis-understood, that's another question for the spec folks. - 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. Not sure I like that. Doing all this policy stuff to provide declarative policies in XML and then eventually say you have to write to javax.security aware piece of code to provide a user and password [1] doesn't sound like a great story to me. Thoughts? [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/demos/secure-bigbank/secure-bigbank-account/src/main/java/bigbank/security/AccountsDataPasswordCallbackHandler.java -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
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? - Why did you need two authentication and wsAuthentication intents? is it because you needed different policy sets on the client and service side? - Did you have to change the WS binding code to support your new user defined wsAuthentication intent? - Is there a way to not repeat the core intents defined by the spec in all contributions? - Where are the bindingType definitions listing the intents provided by the bindings? - What are the security callback handlers responsible for? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
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: tuscany-dev@ws.apache.org 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]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Raymond Feng 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 +1 to try to work through the actual scenario first. When I brought up the scenario I was thinking about the following steps: 1. Copy the bigbank-* modules into new bigbank-secure-* modules. 2. Split the AccountData component into two components in two different composites representing two divisions of the bank (checking and savings accounts). 3. At this point I'm not sure that the calculator component is so interesting for this scenario, as it was there to show integration of different scripting languages, not very relevant here. It's probably more interesting to invoke a CurrencyConverter Web service running on a separate node simulating an external service. 4. Discuss on this list what kind of policies (authentication, confidentiality, integrity) make sense to apply where in the bigbank solution. 5. Author the policy related application and configuration/deployment related artifacts in the bigbank modules; I'm sure that many questions will arise and help understand usage patterns and good practices for policies. 6. Go through the steps that an application developer, assembler, deployer, system administrator needs to perform to put the bigbank solution together; this is not a theoretical exercise as we'll actually have to perform these steps ourselves, and work on what can be done to our policy support to facilitate them. 7. Bring the pieces of the bigbank solution together, get it working end to end and work through any relevant technical issues. I'm guessing that questions like... - how many definitions.xml files to we need? - what do we write in them? - where do we place them? - can intent=confidentiality represent different types of confidentiality mechanisms used for different types of exchanges? - do we put policysets in the composites or definitions.xml - how do we use appliesTo? - and probably 50 more questions like that :) ... will pop up right in our face when we develop the scenario, backed by a concrete use case which will help think through them. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
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: tuscany-dev@ws.apache.org 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]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
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... Could you commit that? it doesn't have to work, I'm sure it's going to take a few weeks before it does, but that'll allow everybody to take a look. I'd suggest to have multiple modules similar to the existing module structure and in addition to that split the account module in three (account, savings-accountdata and checking-accountdata) representing different divisions in the bank. - 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. Yes makes sense - 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 OK - Finally the AccountService should enforce authentication, confidentiality and integrity. Does this sound ok ? Sounds good. More ideas will probably pop up as the scenario matures, but I can think of two other dimensions to this: - Use different confidentiality levels between divisions of the bank and communication with the external world. - Think about the security aspects of the JSP that implements the UI. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
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 - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, November 27, 2007 11:44 AM Subject: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios. Jean-Sebastien Delfino wrote: [snip] I'll propose a scenario in a separate email. Here it goes: - We have support for SCA security policies. - We have a Bigbank application. - A bank application should be secure. Looks like a perfect fit to me. Going through a real world like scenario and trying and showing how to use SCA policies in an application like Bigbank will help our users understand how to use policies. It will also help us improve what we have, mature our policy story and provide feedback to the spec if necessary. To make it real, I'd suggest to look at the Bigbank application and first think about where it'll make business sense to apply authentication, confidentiality, integrity or nothing. To make the scenario a little more interesting we could split checking and savings account management in two divisions of the Bank running different composites. We'll then have to consider: - exchanges within a department - exchanges across departments - exchanges with the outside world ...with different security requirements for each. -- 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]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
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]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
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]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Hi Sebastien, Thanks for providing these hints. I'll get onto this as soon as I have done with some clean up and minor modifications. - Venkat On Nov 28, 2007 1:14 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: [snip] I'll propose a scenario in a separate email. Here it goes: - We have support for SCA security policies. - We have a Bigbank application. - A bank application should be secure. Looks like a perfect fit to me. Going through a real world like scenario and trying and showing how to use SCA policies in an application like Bigbank will help our users understand how to use policies. It will also help us improve what we have, mature our policy story and provide feedback to the spec if necessary. To make it real, I'd suggest to look at the Bigbank application and first think about where it'll make business sense to apply authentication, confidentiality, integrity or nothing. To make the scenario a little more interesting we could split checking and savings account management in two divisions of the Bank running different composites. We'll then have to consider: - exchanges within a department - exchanges across departments - exchanges with the outside world ...with different security requirements for each. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Jean-Sebastien Delfino wrote: [snip] I'll propose a scenario in a separate email. Here it goes: - We have support for SCA security policies. - We have a Bigbank application. - A bank application should be secure. Looks like a perfect fit to me. Going through a real world like scenario and trying and showing how to use SCA policies in an application like Bigbank will help our users understand how to use policies. It will also help us improve what we have, mature our policy story and provide feedback to the spec if necessary. To make it real, I'd suggest to look at the Bigbank application and first think about where it'll make business sense to apply authentication, confidentiality, integrity or nothing. To make the scenario a little more interesting we could split checking and savings account management in two divisions of the Bank running different composites. We'll then have to consider: - exchanges within a department - exchanges across departments - exchanges with the outside world ...with different security requirements for each. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
