Re: [Axis2]Secure + Reliable with SMTP issue
My apologies for not chipping in last week. I have serious reservations about these changes, not least that I disagree with the basic statement: "So whether we run addressing before or after the security the behavior will be the same ." I'll follow up on this in the other thread I've started. David On 26/07/07, Amila Suriarachchi <[EMAIL PROTECTED]> wrote: > > > On 7/26/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > I did some integration tests using Rampart, Sandesha and Addressing. > > > for both http and smtp transports. > > > All those senarios successed with the latest Axis2 and Sandesha builds > > > with the attached Axis2.xml and Sandesha module.xml. (Chamikara helped > > > me a lot in doing this.) > > > Same tests successed with an .Net service using http transport as well. > > > > > > Therefore I belive this phase order is the most correct one to use > > > with full stack. > > > > > > Here we have used a new phase called > > > > > Nope we do not need this phase , and I think we can get the same > > behavior by putting the handler in the Dispatch phase. > > if you are quite sure no problem. > > > Thanks > > Deepal > > > > > > > - > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > Amila Suriarachchi, > WSO2 Inc. -- David Illsley - IBM Web Services Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2]Secure + Reliable with SMTP issue
On 7/26/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: > > > I did some integration tests using Rampart, Sandesha and Addressing. > for both http and smtp transports. > All those senarios successed with the latest Axis2 and Sandesha builds > with the attached Axis2.xml and Sandesha module.xml. (Chamikara helped > me a lot in doing this.) > Same tests successed with an .Net service using http transport as well. > > Therefore I belive this phase order is the most correct one to use > with full stack. > > Here we have used a new phase called > Nope we do not need this phase , and I think we can get the same behavior by putting the handler in the Dispatch phase. if you are quite sure no problem. Thanks Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Amila Suriarachchi, WSO2 Inc.
Re: [Axis2]Secure + Reliable with SMTP issue
> > > I did some integration tests using Rampart, Sandesha and Addressing. > for both http and smtp transports. > All those senarios successed with the latest Axis2 and Sandesha builds > with the attached Axis2.xml and Sandesha module.xml. (Chamikara helped > me a lot in doing this.) > Same tests successed with an .Net service using http transport as well. > > Therefore I belive this phase order is the most correct one to use > with full stack. > > Here we have used a new phase called > Nope we do not need this phase , and I think we can get the same behavior by putting the handler in the Dispatch phase. Thanks Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2]Secure + Reliable with SMTP issue
hi, I did some integration tests using Rampart, Sandesha and Addressing. for both http and smtp transports. All those senarios successed with the latest Axis2 and Sandesha builds with the attached Axis2.xml and Sandesha module.xml. (Chamikara helped me a lot in doing this.) Same tests successed with an .Net service using http transport as well. Therefore I belive this phase order is the most correct one to use with full stack. Here we have used a new phase called to support sandesha. So shall we put this phase as well? When considering this senario a suggestion at sometime to let modules to define there own phases came to my mind. As I remember Glen has made this proposal, I put a +1 and deepal had put a -1. If that feature was there we would have solve this problem without changing the axis2 xml file and letting modules to define their own phases and place them using phase rules. So as I can see this would be a nice to have a feature in Axis2 1.4(obviously not for Axis2 1.3). thanks, Amila. On 7/25/07, Chamikara Jayalath <[EMAIL PROTECTED]> wrote: Hi Guys, +1 For the change. There is another change I would like to propose here. Addressing comes with a AddressingValidationHandler which throws an exception if dispatching has not been done when addressing is present. If we move this to the Addressing Phase as well none of the other dispatchers will work when Addressing is present. This may be theoretically correct. But there may be scenarios where we need the other dispatchers to work even when addressing is present. For example the SequenceIDDIspatcher we introduced in Sandesha2 does the service dispatching based of the WSRM sequence ID. I think we need to have the flexibility in Axis2 to allow the addition of such features. So my proposal is the keep the addressing handlers and the dispachers in the Addressing phase. But to move the validation handler back. Somewhere after dispatchers. Either we can add this as a postCondition fo the Dispatch phase. Or we can add a new DispatchValidation Phase. Chamikara On 7/25/07, Jaliya Ekanayake <[EMAIL PROTECTED]> wrote: > > +1 for adding a new phase and resolve the issue. > That way it clear for anybody to figure out the order > Addressing->Security->RM > -jaliya > - Original Message - > From: "Deepal Jayasinghe" < [EMAIL PROTECTED]> > To: > Sent: Tuesday, July 24, 2007 4:35 AM > Subject: Re: [Axis2]Secure + Reliable with SMTP issue > > > >I will introduce a new phase called "Addressing " and go forward , > let's > > revert that if we found and issue. > > > > Thanks > > Deepal > > > > Sanjiva Weerawarana wrote: > >> +1 ... I think we need to ship an Axis2 that can compose nicely and > >> easily with Rampart and Sandesha to make secure+RM work correctly for > >> HTTP and SMTP (basically for all transports we support). > >> > >> Sanjiva. > >> > >> Deepal Jayasinghe wrote: > >>> Hi Dims, > >>> > >>> No the issues is client side when someone tries to use RM+ Security > then > >>> he has to go and change axis2.xml. Other thing is for security to > work > >>> correctly it is required to have addressing based dispatcher before > >>> security handlers. And using a security is common case so I think > >>> default axis2.xml should support that. > >>> > >>> Thanks > >>> Deepal > >>>> Deepal, > >>>> > >>>> IMHO, This can be documented and fixed post 1.3 I can see folks who > > >>>> are working on an advanced scenario comfortable with a custom > >>>> axis2.xml. > >>>> > >>>> thanks, > >>>> dims > >>>> > > > > > > > > - > > 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] > > -- Chamikara Jayalath WSO2 Inc. http://wso2.com/ http://wso2.org/ - For your Oxygen needs -- Amila Suriarachchi, WSO2 Inc. true false false false 3 false false admin axis2 false http://www.w3.org/20
Re: [Axis2]Secure + Reliable with SMTP issue
Hi Guys, +1 For the change. There is another change I would like to propose here. Addressing comes with a AddressingValidationHandler which throws an exception if dispatching has not been done when addressing is present. If we move this to the Addressing Phase as well none of the other dispatchers will work when Addressing is present. This may be theoretically correct. But there may be scenarios where we need the other dispatchers to work even when addressing is present. For example the SequenceIDDIspatcher we introduced in Sandesha2 does the service dispatching based of the WSRM sequence ID. I think we need to have the flexibility in Axis2 to allow the addition of such features. So my proposal is the keep the addressing handlers and the dispachers in the Addressing phase. But to move the validation handler back. Somewhere after dispatchers. Either we can add this as a postCondition fo the Dispatch phase. Or we can add a new DispatchValidation Phase. Chamikara On 7/25/07, Jaliya Ekanayake <[EMAIL PROTECTED]> wrote: +1 for adding a new phase and resolve the issue. That way it clear for anybody to figure out the order Addressing->Security->RM -jaliya - Original Message - From: "Deepal Jayasinghe" <[EMAIL PROTECTED]> To: Sent: Tuesday, July 24, 2007 4:35 AM Subject: Re: [Axis2]Secure + Reliable with SMTP issue >I will introduce a new phase called "Addressing " and go forward , let's > revert that if we found and issue. > > Thanks > Deepal > > Sanjiva Weerawarana wrote: >> +1 ... I think we need to ship an Axis2 that can compose nicely and >> easily with Rampart and Sandesha to make secure+RM work correctly for >> HTTP and SMTP (basically for all transports we support). >> >> Sanjiva. >> >> Deepal Jayasinghe wrote: >>> Hi Dims, >>> >>> No the issues is client side when someone tries to use RM+ Security then >>> he has to go and change axis2.xml. Other thing is for security to work >>> correctly it is required to have addressing based dispatcher before >>> security handlers. And using a security is common case so I think >>> default axis2.xml should support that. >>> >>> Thanks >>> Deepal >>>> Deepal, >>>> >>>> IMHO, This can be documented and fixed post 1.3 I can see folks who >>>> are working on an advanced scenario comfortable with a custom >>>> axis2.xml. >>>> >>>> thanks, >>>> dims >>>> > > > > - > 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] -- Chamikara Jayalath WSO2 Inc. http://wso2.com/ http://wso2.org/ - For your Oxygen needs
Re: [Axis2]Secure + Reliable with SMTP issue
+1 for adding a new phase and resolve the issue. That way it clear for anybody to figure out the order Addressing->Security->RM -jaliya - Original Message - From: "Deepal Jayasinghe" <[EMAIL PROTECTED]> To: Sent: Tuesday, July 24, 2007 4:35 AM Subject: Re: [Axis2]Secure + Reliable with SMTP issue I will introduce a new phase called "Addressing " and go forward , let's revert that if we found and issue. Thanks Deepal Sanjiva Weerawarana wrote: +1 ... I think we need to ship an Axis2 that can compose nicely and easily with Rampart and Sandesha to make secure+RM work correctly for HTTP and SMTP (basically for all transports we support). Sanjiva. Deepal Jayasinghe wrote: Hi Dims, No the issues is client side when someone tries to use RM+ Security then he has to go and change axis2.xml. Other thing is for security to work correctly it is required to have addressing based dispatcher before security handlers. And using a security is common case so I think default axis2.xml should support that. Thanks Deepal Deepal, IMHO, This can be documented and fixed post 1.3 I can see folks who are working on an advanced scenario comfortable with a custom axis2.xml. thanks, dims - 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: [Axis2]Secure + Reliable with SMTP issue
+1 on Adding a new phase and moving addressing BasedDistpacher before the Security. In this way we can support operational level security polices. I think it is very difficult for a new person to debug and find this problem (handler chain order) if we have shif it in wrong way. Since one of the objectives of Axis2 1.3 to provide a Sandesha and rampart compatible Axis2 release it would be nice to have this for Axis2 1.3. Thanks Amila. On 7/24/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: I will introduce a new phase called "Addressing " and go forward , let's revert that if we found and issue. Thanks Deepal Sanjiva Weerawarana wrote: > +1 ... I think we need to ship an Axis2 that can compose nicely and > easily with Rampart and Sandesha to make secure+RM work correctly for > HTTP and SMTP (basically for all transports we support). > > Sanjiva. > > Deepal Jayasinghe wrote: >> Hi Dims, >> >> No the issues is client side when someone tries to use RM+ Security then >> he has to go and change axis2.xml. Other thing is for security to work >> correctly it is required to have addressing based dispatcher before >> security handlers. And using a security is common case so I think >> default axis2.xml should support that. >> >> Thanks >> Deepal >>> Deepal, >>> >>> IMHO, This can be documented and fixed post 1.3 I can see folks who >>> are working on an advanced scenario comfortable with a custom >>> axis2.xml. >>> >>> thanks, >>> dims >>> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Amila Suriarachchi, WSO2 Inc.
Re: [Axis2]Secure + Reliable with SMTP issue
I will introduce a new phase called "Addressing " and go forward , let's revert that if we found and issue. Thanks Deepal Sanjiva Weerawarana wrote: > +1 ... I think we need to ship an Axis2 that can compose nicely and > easily with Rampart and Sandesha to make secure+RM work correctly for > HTTP and SMTP (basically for all transports we support). > > Sanjiva. > > Deepal Jayasinghe wrote: >> Hi Dims, >> >> No the issues is client side when someone tries to use RM+ Security then >> he has to go and change axis2.xml. Other thing is for security to work >> correctly it is required to have addressing based dispatcher before >> security handlers. And using a security is common case so I think >> default axis2.xml should support that. >> >> Thanks >> Deepal >>> Deepal, >>> >>> IMHO, This can be documented and fixed post 1.3 I can see folks who >>> are working on an advanced scenario comfortable with a custom >>> axis2.xml. >>> >>> thanks, >>> dims >>> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2]Secure + Reliable with SMTP issue
+1 ... I think we need to ship an Axis2 that can compose nicely and easily with Rampart and Sandesha to make secure+RM work correctly for HTTP and SMTP (basically for all transports we support). Sanjiva. Deepal Jayasinghe wrote: Hi Dims, No the issues is client side when someone tries to use RM+ Security then he has to go and change axis2.xml. Other thing is for security to work correctly it is required to have addressing based dispatcher before security handlers. And using a security is common case so I think default axis2.xml should support that. Thanks Deepal Deepal, IMHO, This can be documented and fixed post 1.3 I can see folks who are working on an advanced scenario comfortable with a custom axis2.xml. thanks, dims On 7/23/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: Hi all. In oder to get security to work in one way transport (like SMTP) we need to have addressing around. In simple word the only way to dispatch service and operation is using addressing. According to my knowledge addressing headers will not encrypt in the practical scenario though it is possible in theoretically , therefore we can safely assume that one can sign wsa headers but not encrypt. So we can run addressing handlers and addressing based dispatchers before security handlers. If someone has intercepted the message when the addressing headers has signed , then when it come to security handlers it will identify that and throw exception . So whether we run addressing before or after the security the behavior will be the same . So we can move addressing handlers before security handlers , next the question is to where do we move them . In this case we have two options Option 1: Move PreDispatch phase before security phase (since all the addressing handlers in the PreDispatch) Option 2 : Introduce new phase called "Addressing" before the security phase and keep the PreDispatch has it is If we do the first option then we are breaking the backward compatibility (That is why I reverted my change 558707) , and semantically the phase will not the PreDispatch since it is before the security phase (rather PreSecurity). If we do the second option we will not break the backward compatibility and will introduce a very meaningfully phase to deploy addressing handlers. Since this is going to be a configuration file change , I would like to do that before 1.3. And the important thing is we can not get security + addressing working in SMTP or any other one way transport without moving addressing handlers. So if we are doing so we need to do it properly , I personally think the option 2 is the most suitable option and I am +1 for going forward with option2 and implement that for 1.3 Thanks Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder & Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ Director; Open Source Initiative; http://www.opensource.org/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2]Secure + Reliable with SMTP issue
Hi Dims, No the issues is client side when someone tries to use RM+ Security then he has to go and change axis2.xml. Other thing is for security to work correctly it is required to have addressing based dispatcher before security handlers. And using a security is common case so I think default axis2.xml should support that. Thanks Deepal > Deepal, > > IMHO, This can be documented and fixed post 1.3 I can see folks who > are working on an advanced scenario comfortable with a custom > axis2.xml. > > thanks, > dims > > On 7/23/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: >> Hi all. >> >> >> In oder to get security to work in one way transport (like SMTP) we need >> to have addressing around. In simple word the only way to dispatch >> service and operation is using addressing. According to my knowledge >> addressing headers will not encrypt in the practical scenario though it >> is possible in theoretically , therefore we can safely assume that one >> can sign wsa headers but not encrypt. So we can run addressing handlers >> and addressing based dispatchers before security handlers. If someone >> has intercepted the message when the addressing headers has signed , >> then when it come to security handlers it will identify that and throw >> exception . So whether we run addressing before or after the security >> the behavior will be the same . >> >> So we can move addressing handlers before security handlers , next the >> question is to where do we move them . In this case we have two options >> >> Option 1: Move PreDispatch phase before security phase (since all the >> addressing handlers in the PreDispatch) >> Option 2 : Introduce new phase called "Addressing" before the security >> phase and keep the PreDispatch has it is >> >> If we do the first option then we are breaking the backward >> compatibility (That is why I reverted my change 558707) , and >> semantically the phase will not the PreDispatch since it is before the >> security phase (rather PreSecurity). >> >> If we do the second option we will not break the backward compatibility >> and will introduce a very meaningfully phase to deploy addressing >> handlers. >> >> Since this is going to be a configuration file change , I would like to >> do that before 1.3. And the important thing is we can not get security + >> addressing working in SMTP or any other one way transport without moving >> addressing handlers. So if we are doing so we need to do it properly , I >> personally think the option 2 is the most suitable option and I am +1 >> for going forward with option2 and implement that for 1.3 >> >> Thanks >> Deepal >> >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- Thanks, Deepal "The highest tower is built one brick at a time" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2]Secure + Reliable with SMTP issue
Deepal, IMHO, This can be documented and fixed post 1.3 I can see folks who are working on an advanced scenario comfortable with a custom axis2.xml. thanks, dims On 7/23/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: Hi all. In oder to get security to work in one way transport (like SMTP) we need to have addressing around. In simple word the only way to dispatch service and operation is using addressing. According to my knowledge addressing headers will not encrypt in the practical scenario though it is possible in theoretically , therefore we can safely assume that one can sign wsa headers but not encrypt. So we can run addressing handlers and addressing based dispatchers before security handlers. If someone has intercepted the message when the addressing headers has signed , then when it come to security handlers it will identify that and throw exception . So whether we run addressing before or after the security the behavior will be the same . So we can move addressing handlers before security handlers , next the question is to where do we move them . In this case we have two options Option 1: Move PreDispatch phase before security phase (since all the addressing handlers in the PreDispatch) Option 2 : Introduce new phase called "Addressing" before the security phase and keep the PreDispatch has it is If we do the first option then we are breaking the backward compatibility (That is why I reverted my change 558707) , and semantically the phase will not the PreDispatch since it is before the security phase (rather PreSecurity). If we do the second option we will not break the backward compatibility and will introduce a very meaningfully phase to deploy addressing handlers. Since this is going to be a configuration file change , I would like to do that before 1.3. And the important thing is we can not get security + addressing working in SMTP or any other one way transport without moving addressing handlers. So if we are doing so we need to do it properly , I personally think the option 2 is the most suitable option and I am +1 for going forward with option2 and implement that for 1.3 Thanks Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2]Secure + Reliable with SMTP issue
Hi all. In oder to get security to work in one way transport (like SMTP) we need to have addressing around. In simple word the only way to dispatch service and operation is using addressing. According to my knowledge addressing headers will not encrypt in the practical scenario though it is possible in theoretically , therefore we can safely assume that one can sign wsa headers but not encrypt. So we can run addressing handlers and addressing based dispatchers before security handlers. If someone has intercepted the message when the addressing headers has signed , then when it come to security handlers it will identify that and throw exception . So whether we run addressing before or after the security the behavior will be the same . So we can move addressing handlers before security handlers , next the question is to where do we move them . In this case we have two options Option 1: Move PreDispatch phase before security phase (since all the addressing handlers in the PreDispatch) Option 2 : Introduce new phase called “Addressing” before the security phase and keep the PreDispatch has it is If we do the first option then we are breaking the backward compatibility (That is why I reverted my change 558707) , and semantically the phase will not the PreDispatch since it is before the security phase (rather PreSecurity). If we do the second option we will not break the backward compatibility and will introduce a very meaningfully phase to deploy addressing handlers. Since this is going to be a configuration file change , I would like to do that before 1.3. And the important thing is we can not get security + addressing working in SMTP or any other one way transport without moving addressing handlers. So if we are doing so we need to do it properly , I personally think the option 2 is the most suitable option and I am +1 for going forward with option2 and implement that for 1.3 Thanks Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
