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]
