You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Ruchith Fernando <ru...@gmail.com> on 2005/08/25 11:57:29 UTC
[Axis2] Phase of Inflow Security Handler
Hi All,
When security is enabled for a certain service, the inflow security
handler (WSDoAllReceiver) will have to be invoked on requests to that
perticular service.
Therefore we will have to deploy the WSDoAllReceiver within the
"Dispatch" phase after the "RequestURIBasedDispatcher".
But the Axis2 right now enforces the "AddressingBasedDispatcher" to be
run ahead of all the others and this order is not configurable. But
IMHO we should not access the other SOAP headers before the security
processing is complete.
Since RequestURIBasedDispatcher is the only possible mechanism to
figureout the service without accessing the other SOAP headers (e.g.
wsa headers) and the SOAP bosy, can we change the order of the
dispatchers, or can we make it configurable such that its possible to
change the dispatch order (to have the RequestURIBasedDispatcher
first), when the security module is engaged?
Thanks,
--
Ruchith
Re: [Axis2] Phase of Inflow Security Handler
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Chinthaka, Ruchith:
>> Since RequestURIBasedDispatcher is the only possible mechanism to
>> figureout the service without accessing the other SOAP headers (e.g.
>> wsa headers) and the SOAP bosy, can we change the order of the
>> dispatchers, or can we make it configurable such that its possible to
>> change the dispatch order (to have the RequestURIBasedDispatcher
>> first), when the security module is engaged?
>
> Agreed, but for HTTPand SMTP only. What about for the TCP case ? Service
> identification based on the socket information ? If so, fine.
>
> So lets have a phase called "DispatchPhaseOne". And the rest in
> "DispatchPhaseTwo".
1) Transport-based dispatchers should be in the transport phase, not the
global dispatch phase. Thus they should always run before anything like
WS-Addressing dispatch. Doing dispatch based on URI or port or any kind
of binary/text header outside the SOAP envelope is always going to be
faster than cracking the body and reading WSA headers, so we should let
that happen first.
2) -1 to "DispatchPhaseOne"/"DispatchPhaseTwo". I don't think this is
necessary.
3) I still don't see the need for a "PreDispatch" or a "PostDispatch"
phase. Isn't the whole point of configurable phases/handlers that you
can say things like "BEFORE Dispatch" and "AFTER Dispatch" as rules?
What's the difference between having an explicit "PreDispatch" container
and just saying "BEFORE Dispatch"?
--Glen
Re: [Axis2] Phase of Inflow Security Handler
Posted by Srinath Perera <he...@gmail.com>.
ok, users do not change the dispatcers frquesntly. So we do not need a
seperate Dispatcher, and just having a handler will be good enough ..
But right now we have hardcoded some dispatchers in the source code ..
maybe we should take them to the axis2.xml
Srinath
On 8/25/05, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi all:
>
> Srinath Perera wrote:
> > I agree with ruchith somewhat, since the URL, the
> > "RequestURIBasedDispatcher" would operates on, is not usually
> > encrypted (not in the domein of WS security .. right?) so it can (at
> > least in theory) could work before the security Handler!
>
> Right - same with SOAPAction-based dispatch, or anything else outside
> the SOAP envelope (i.e. transport-specific).
>
> > 1) But do we need a DispatchPhaseOne .. why d'not we use the phase
> > first ect to order them (rules phaseFirst functional?)
>
> Why?
>
> > 2) we need to find some way to make the Dispatchers configurable via
> > the axis2.xml .. how about adding a <dispatcher ...> tag and put all
> > our defult dispatchers in to axis2.xml
>
> Hm - isn't a "dispatcher" just any old Handler that happens to know how
> to set the service/operation/messageReference? It's not (and shouldn't
> be) anything different or special.... If you make a special class of
> "dispatchers" you then need to define the meaning of that, extra
> semantics, etc., none of which I believe is necessary.
>
> I think the only thing that matters is that at the end of the Dispatch
> phase, the post-condition must be met. The whole point is to allow
> maximal flexibility in terms of how and when that might occur.
>
> --Glen
>
Re: [Axis2] Phase of Inflow Security Handler
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi all:
Srinath Perera wrote:
> I agree with ruchith somewhat, since the URL, the
> "RequestURIBasedDispatcher" would operates on, is not usually
> encrypted (not in the domein of WS security .. right?) so it can (at
> least in theory) could work before the security Handler!
Right - same with SOAPAction-based dispatch, or anything else outside
the SOAP envelope (i.e. transport-specific).
> 1) But do we need a DispatchPhaseOne .. why d'not we use the phase
> first ect to order them (rules phaseFirst functional?)
Why?
> 2) we need to find some way to make the Dispatchers configurable via
> the axis2.xml .. how about adding a <dispatcher ...> tag and put all
> our defult dispatchers in to axis2.xml
Hm - isn't a "dispatcher" just any old Handler that happens to know how
to set the service/operation/messageReference? It's not (and shouldn't
be) anything different or special.... If you make a special class of
"dispatchers" you then need to define the meaning of that, extra
semantics, etc., none of which I believe is necessary.
I think the only thing that matters is that at the end of the Dispatch
phase, the post-condition must be met. The whole point is to allow
maximal flexibility in terms of how and when that might occur.
--Glen
Re: [Axis2] Phase of Inflow Security Handler
Posted by Srinath Perera <he...@gmail.com>.
Hi guys;
I agree with ruchith somewhat, since the URL, the
"RequestURIBasedDispatcher" would operates on, is not usually
encrypted (not in the domein of WS security .. right?) so it can (at
least in theory) could work before the security Handler!
1) But do we need a DispatchPhaseOne .. why d'not we use the phase
first ect to order them (rules phaseFirst functional?)
2) we need to find some way to make the Dispatchers configurable via
the axis2.xml .. how about adding a <dispatcher ...> tag and put all
our defult dispatchers in to axis2.xml
Srinath
On 8/25/05, Ajith Ranabahu <aj...@gmail.com> wrote:
> IMHO I don't think anything can be there before the security handler (Say
> the WHOLE message is encrypted). So in most cases we have to run the
> security handler as early as possible, but in some other cases we should
> wait a bit.
> My guess is since it's possible to deploy the same handler in several
> places, we can place the security handler in the possible places where
> security can be implemented, say at the begining of the predispatch and
> inside the dispatch phases. The security handle should have fall through
> code to handle it though. we might also need a flag (probably in the MC
> properties) to say that the security is done!
>
>
> On 8/25/05, Eran Chinthaka <chinthaka@opensource.lk > wrote:
> > No this will not help.
> > There can be some handlers in the pre-dispatch phase, which can not
> operate before Security, if present, but need to operate before dispatching.
> >
> > -- EC
> >
> >
> > Ruchith Fernando wrote:
> > So are we going to include the "RequestURIBasedDispatcher" in
> > "DispatchPhaseOne".
> >
> > If that is the case we simply change the order of the dispatchers in
> > the "Dispatch" phase, by slightly modifying
> > org.apache.axis2.engine.AxisConfigurationImpl and deploy
> the security
> > IN handler in the "Dispatch" phase 'after' the
> > "RequestURIBasedDispatcher".
> >
> > I don't think we really need two dispatch phases like that, since this
> > seems to be a requirement unique to the security module. what do u
> > think?
> >
> > --Ruchith
> >
> > On 8/25/05, Eran Chinthaka
<ch...@opensource.lk> wrote:
> >
> >
> > Agreed, but for HTTPand SMTP only. What about for the TCP case ? Service
> > identification based on the socket information ? If so, fine.
> >
> > So lets have a phase called "DispatchPhaseOne". And the rest in
> > "DispatchPhaseTwo".
> >
> > Ruchith Fernando wrote:
> >
> >
> >
> > Hi All,
> >
> > When security is enabled for a certain service, the inflow security
> > handler (WSDoAllReceiver) will have to be invoked on requests to that
> > perticular service.
> >
> > Therefore we will have to deploy the WSDoAllReceiver within the
> > "Dispatch" phase after the "RequestURIBasedDispatcher".
> >
> > But the Axis2 right now enforces the "AddressingBasedDispatcher" to be
> > run ahead of all the others and this order is not configurable. But
> > IMHO we should not access the other SOAP headers before the security
> > processing is complete.
> >
> > Since RequestURIBasedDispatcher is the only possible mechanism to
> > figureout the service without accessing the other SOAP headers (
e.g.
> > wsa headers) and the SOAP bosy, can we change the order of the
> > dispatchers, or can we make it configurable such that its possible to
> > change the dispatch order (to have the RequestURIBasedDispatcher
> > first), when the security module is engaged?
> >
> > Thanks,
> > --
> > Ruchith
> >
> >
> >
> >
> >
> >
> >
>
>
>
> --
> Ajith Ranabahu
Re: [Axis2] Phase of Inflow Security Handler
Posted by Ajith Ranabahu <aj...@gmail.com>.
IMHO I don't think anything can be there before the security handler (Say
the WHOLE message is encrypted). So in most cases we have to run the
security handler as early as possible, but in some other cases we should
wait a bit.
My guess is since it's possible to deploy the same handler in several
places, we can place the security handler in the possible places where
security can be implemented, say at the begining of the predispatch and
inside the dispatch phases. The security handle should have fall through
code to handle it though. we might also need a flag (probably in the MC
properties) to say that the security is done!
On 8/25/05, Eran Chinthaka <ch...@opensource.lk> wrote:
>
> No this will not help.
> There can be some handlers in the pre-dispatch phase, which can not
> operate before Security, if present, but need to operate before dispatching.
>
>
> -- EC
>
> Ruchith Fernando wrote:
>
> So are we going to include the "RequestURIBasedDispatcher" in
> "DispatchPhaseOne".
>
> If that is the case we simply change the order of the dispatchers in
> the "Dispatch" phase, by slightly modifying
> org.apache.axis2.engine.AxisConfigurationImpl and deploy the security
> IN handler in the "Dispatch" phase 'after' the
> "RequestURIBasedDispatcher".
>
> I don't think we really need two dispatch phases like that, since this
> seems to be a requirement unique to the security module. what do u
> think?
>
> --Ruchith
>
> On 8/25/05, Eran Chinthaka <ch...@opensource.lk> <ch...@opensource.lk> wrote:
>
> Agreed, but for HTTPand SMTP only. What about for the TCP case ? Service
> identification based on the socket information ? If so, fine.
>
> So lets have a phase called "DispatchPhaseOne". And the rest in
> "DispatchPhaseTwo".
>
> Ruchith Fernando wrote:
>
> Hi All,
>
> When security is enabled for a certain service, the inflow security
> handler (WSDoAllReceiver) will have to be invoked on requests to that
> perticular service.
>
> Therefore we will have to deploy the WSDoAllReceiver within the
> "Dispatch" phase after the "RequestURIBasedDispatcher".
>
> But the Axis2 right now enforces the "AddressingBasedDispatcher" to be
> run ahead of all the others and this order is not configurable. But
> IMHO we should not access the other SOAP headers before the security
> processing is complete.
>
> Since RequestURIBasedDispatcher is the only possible mechanism to
> figureout the service without accessing the other SOAP headers (e.g.
> wsa headers) and the SOAP bosy, can we change the order of the
> dispatchers, or can we make it configurable such that its possible to
> change the dispatch order (to have the RequestURIBasedDispatcher
> first), when the security module is engaged?
>
> Thanks,
> --
> Ruchith
>
>
>
>
--
Ajith Ranabahu
Re: [Axis2] Phase of Inflow Security Handler
Posted by Eran Chinthaka <ch...@opensource.lk>.
No this will not help.
There can be some handlers in the pre-dispatch phase, which can not
operate before Security, if present, but need to operate before
dispatching.
-- EC
Ruchith Fernando wrote:
>So are we going to include the "RequestURIBasedDispatcher" in
>"DispatchPhaseOne".
>
>If that is the case we simply change the order of the dispatchers in
>the "Dispatch" phase, by slightly modifying
>org.apache.axis2.engine.AxisConfigurationImpl and deploy the security
>IN handler in the "Dispatch" phase 'after' the
>"RequestURIBasedDispatcher".
>
>I don't think we really need two dispatch phases like that, since this
>seems to be a requirement unique to the security module. what do u
>think?
>
>--Ruchith
>
>On 8/25/05, Eran Chinthaka <ch...@opensource.lk> wrote:
>
>
>>Agreed, but for HTTPand SMTP only. What about for the TCP case ? Service
>>identification based on the socket information ? If so, fine.
>>
>>So lets have a phase called "DispatchPhaseOne". And the rest in
>>"DispatchPhaseTwo".
>>
>>Ruchith Fernando wrote:
>>
>>
>>
>>>Hi All,
>>>
>>>When security is enabled for a certain service, the inflow security
>>>handler (WSDoAllReceiver) will have to be invoked on requests to that
>>>perticular service.
>>>
>>>Therefore we will have to deploy the WSDoAllReceiver within the
>>>"Dispatch" phase after the "RequestURIBasedDispatcher".
>>>
>>>But the Axis2 right now enforces the "AddressingBasedDispatcher" to be
>>>run ahead of all the others and this order is not configurable. But
>>>IMHO we should not access the other SOAP headers before the security
>>>processing is complete.
>>>
>>>Since RequestURIBasedDispatcher is the only possible mechanism to
>>>figureout the service without accessing the other SOAP headers (e.g.
>>>wsa headers) and the SOAP bosy, can we change the order of the
>>>dispatchers, or can we make it configurable such that its possible to
>>>change the dispatch order (to have the RequestURIBasedDispatcher
>>>first), when the security module is engaged?
>>>
>>>Thanks,
>>>--
>>>Ruchith
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
Re: [Axis2] Phase of Inflow Security Handler
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi all;
as I know addressing handler can override URL information , so my idea the
dispatching order what we have currently is correct. So
AddressingBasedDisptacher should before URLbasedDispatcher .
If we are trying to change this , we are trying to change the axis2
dispatching order due to security requirement. So if the security is not
there we are going to change dispatching order .
cant we find a some other way to solve this ??
Thanks,
Deepal
................................................................
~Future is Open~
----- Original Message -----
From: "Ruchith Fernando" <ru...@gmail.com>
To: <ax...@ws.apache.org>; <ch...@opensource.lk>
Sent: Thursday, August 25, 2005 4:20 PM
Subject: Re: [Axis2] Phase of Inflow Security Handler
r
So are we going to include the "RequestURIBasedDispatcher" in
"DispatchPhaseOne".
If that is the case we simply change the order of the dispatchers in
the "Dispatch" phase, by slightly modifying
org.apache.axis2.engine.AxisConfigurationImpl and deploy the security
IN handler in the "Dispatch" phase 'after' the
"RequestURIBasedDispatcher".
I don't think we really need two dispatch phases like that, since this
seems to be a requirement unique to the security module. what do u
think?
--Ruchith
On 8/25/05, Eran Chinthaka <ch...@opensource.lk> wrote:
> Agreed, but for HTTPand SMTP only. What about for the TCP case ? Service
> identification based on the socket information ? If so, fine.
>
> So lets have a phase called "DispatchPhaseOne". And the rest in
> "DispatchPhaseTwo".
>
> Ruchith Fernando wrote:
>
> >Hi All,
> >
> >When security is enabled for a certain service, the inflow security
> >handler (WSDoAllReceiver) will have to be invoked on requests to that
> >perticular service.
> >
> >Therefore we will have to deploy the WSDoAllReceiver within the
> >"Dispatch" phase after the "RequestURIBasedDispatcher".
> >
> >But the Axis2 right now enforces the "AddressingBasedDispatcher" to be
> >run ahead of all the others and this order is not configurable. But
> >IMHO we should not access the other SOAP headers before the security
> >processing is complete.
> >
> >Since RequestURIBasedDispatcher is the only possible mechanism to
> >figureout the service without accessing the other SOAP headers (e.g.
> >wsa headers) and the SOAP bosy, can we change the order of the
> >dispatchers, or can we make it configurable such that its possible to
> >change the dispatch order (to have the RequestURIBasedDispatcher
> >first), when the security module is engaged?
> >
> >Thanks,
> >--
> >Ruchith
> >
> >
> >
>
>
--
Ruchith
Re: [Axis2] Phase of Inflow Security Handler
Posted by Ruchith Fernando <ru...@gmail.com>.
So are we going to include the "RequestURIBasedDispatcher" in
"DispatchPhaseOne".
If that is the case we simply change the order of the dispatchers in
the "Dispatch" phase, by slightly modifying
org.apache.axis2.engine.AxisConfigurationImpl and deploy the security
IN handler in the "Dispatch" phase 'after' the
"RequestURIBasedDispatcher".
I don't think we really need two dispatch phases like that, since this
seems to be a requirement unique to the security module. what do u
think?
--Ruchith
On 8/25/05, Eran Chinthaka <ch...@opensource.lk> wrote:
> Agreed, but for HTTPand SMTP only. What about for the TCP case ? Service
> identification based on the socket information ? If so, fine.
>
> So lets have a phase called "DispatchPhaseOne". And the rest in
> "DispatchPhaseTwo".
>
> Ruchith Fernando wrote:
>
> >Hi All,
> >
> >When security is enabled for a certain service, the inflow security
> >handler (WSDoAllReceiver) will have to be invoked on requests to that
> >perticular service.
> >
> >Therefore we will have to deploy the WSDoAllReceiver within the
> >"Dispatch" phase after the "RequestURIBasedDispatcher".
> >
> >But the Axis2 right now enforces the "AddressingBasedDispatcher" to be
> >run ahead of all the others and this order is not configurable. But
> >IMHO we should not access the other SOAP headers before the security
> >processing is complete.
> >
> >Since RequestURIBasedDispatcher is the only possible mechanism to
> >figureout the service without accessing the other SOAP headers (e.g.
> >wsa headers) and the SOAP bosy, can we change the order of the
> >dispatchers, or can we make it configurable such that its possible to
> >change the dispatch order (to have the RequestURIBasedDispatcher
> >first), when the security module is engaged?
> >
> >Thanks,
> >--
> >Ruchith
> >
> >
> >
>
>
--
Ruchith
Re: [Axis2] Phase of Inflow Security Handler
Posted by Eran Chinthaka <ch...@opensource.lk>.
Agreed, but for HTTPand SMTP only. What about for the TCP case ? Service
identification based on the socket information ? If so, fine.
So lets have a phase called "DispatchPhaseOne". And the rest in
"DispatchPhaseTwo".
Ruchith Fernando wrote:
>Hi All,
>
>When security is enabled for a certain service, the inflow security
>handler (WSDoAllReceiver) will have to be invoked on requests to that
>perticular service.
>
>Therefore we will have to deploy the WSDoAllReceiver within the
>"Dispatch" phase after the "RequestURIBasedDispatcher".
>
>But the Axis2 right now enforces the "AddressingBasedDispatcher" to be
>run ahead of all the others and this order is not configurable. But
>IMHO we should not access the other SOAP headers before the security
>processing is complete.
>
>Since RequestURIBasedDispatcher is the only possible mechanism to
>figureout the service without accessing the other SOAP headers (e.g.
>wsa headers) and the SOAP bosy, can we change the order of the
>dispatchers, or can we make it configurable such that its possible to
>change the dispatch order (to have the RequestURIBasedDispatcher
>first), when the security module is engaged?
>
>Thanks,
>--
>Ruchith
>
>
>