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 Srinath Perera <he...@gmail.com> on 2006/02/13 23:29:58 UTC
State of WS-Policy?
Hi All;
I want to ask the state of our policy implementation, and how much the
policy descriptions are bound to modules?
I saw from the code, if there are modules engaged, they are printed
out in WSDL as policy, do we support other side, engaging and
configure the
modules according to the WS-Policy information given in Axis2 configuration.
I am more interested in having the policy support in the client side,
and I believe it should be WSDL based. Have we done any work on it? If
not I would like to try to do something on the enabling them on the
dynamic client interface (give a wsdl and configure the
ServiceCleint/OperationClient) as a start
I wrote few thoughts and a possible implementation down, I think most
of it is already done. I want to tie the loose threads and use it and
to fix what ever I can. Please comment.
Thanks
Srinath
WS-Policy and Axis2 Modules are kind of parallel, I would view them as
one is abstract representation and other is implementation of the
representation. To build a policy model for Axis2 we need to describe
two scenarios
1) Build a Service, engage Modules and then create a WSDL description.
This is the most natural scenario for the Server side
2) Given a WSDL, extract the Policy and create a Service with modules engaged
The main work we have to do is
1) Provide a mapping from a given type of policy to a specific module,
then hand over handling that policy to module
2) Define the parameter conversion to and from the Policy, we have two options
a) We can define a mapping from policy to the our parameters in the modules
b) We can use policy segments inside the service.xml file, for
an example for security module
Possible Implementation
=======================
1) Every module register a name space of the policy it can handle
2) If we start from Axis2 configuration Modules at engagement receive
the policy directly or via the service. The Policy could be Axis2
parameters or Policy xml segment. Following is example of policy
segment in engagement.
<service name="SecureService">
<engage name="">
<wsp:Policy>
...............
<sp:SignedSupportingTokens>
<wsp:Policy>
<sp:UsernameToken
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Once"
/>
</wsp:Policy>
</sp:SignedSupportingTokens>
..........
</wsp:Policy>
</enagege>
</service>
3) When a WSDL is found with policy included, a module is called
based on the #1 mapping, and module is able to process the policy and
configure and engage himself
Re: Fwd:[Axis2] State of WS-Policy?
Posted by Sanka Samaranayake <ss...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eran Chinthaka wrote:
> Good explanation. Can we have this on wiki ?
yes .. I'll do
Sanka
>
> Sanka Samaranayake wrote:
>
>
>>Hi Srinath, all,
>>
>>At this point, Axis2 Codegen does support WS Policies at client-side.
>>
>>Let me briefly explain how it happens..
>>
>>Phase1: (At PolicyEvaluator)
>>
>>Codegen engine runs few of its registered extension before it generates
>>the stub. When PolicyEvalutor (which is a registered Codegen extension)
>>is initialized it populates a registry of namespaces of supported
>>policies to module. For instance module foo might have a mapping of
>>namespace http://test.com/foo which means any primitive assertion which
>>has this namespace will be processed by this module.
>>
>>e.g. <mns:MyAssertion xmlns:mns="http:tests.org/foo">
>> ...
>> </mns:MyAssertion>
>>
>>In other words the above assertion in a policy will be processed by the
>>module 'foo'. Those modules are located using the repository-path which
>>is given as an argument.
>>
>>Then at the engagement, effective policy of each operation is calculated
>>based on policy information declared in the WSDL document. Here we
>>assumes that effective policy of an operation contains a single
>>alternative (Multiple policy alternatives are not supported). Then we
>>split that policy into few other policies such that each policy will
>>contains primitive assertions belonging to only one namespace
>>
>><wsp:Policy> <wsp:Policy> <wsp:Policy> <wsp:Policy>
>> <a:Foo/> <a:Foo/> <b:Foo/> <c:Bar/>
>> <a:Bar/> => <a:Bar/> </wsp:Policy> </wsp:Policy>
>> <b:Foo/> </wsp:Policy>
>> <c:Bar/>
>></wsp:Policy>
>>
>>Then each policy is given to the appropriate module with an
>>org.w3c.Element type object to which the module can append any
>>other elements/attributes it wishes. Those attributes/elements should
>>resolved to meaningful stub functions via PolicyExtensionTemplate.xsl at
>>latter point of time.
>>
>>For instance depending on the policy, Security module can append
>><username>, <passwd> elements to the given element as children, which
>>are later resolved into setUsername(..), setPasswd(..), functions of the
>>stub. This way a module can add additional methods to the stub which can
>>be used get specific parameters to the module. Those methods store any
>>user input in the ServiceClient properties
>>(ServiceClient.getOptions().putProperty(...)) which can later be access
>>by the module.
>>
>>Phase2: (At MultiLanguageClientEmitter)
>>
>>Further, effective policies (based on the WSDL) at appropriate levels
>>(service level, operation level) are stored as policy strings in the
>>stub. Few more generic methods are also added to the stub which are used
>> to evaluate/processing policies at runtime.
>>
>>Runtime:
>>
>>When a new stub object is created, the policy strings in the stub are
>>converted into policy objects and merge together to get the effective
>>policies of each operation. That policy information is stored in the
>>AxisOperation object which a module can access at later point of time.
>>
>>Then based on its policy each AxisOperation is engaged to a set of
>>modules.
>>
>>And when the stub method is invoked, those modules which are engaged to
>>that AxisOperation, access the policy information for that operation via
>>AxisOperation object. It can get other information needed from the
>>MessageContext which are get stored by stub methods which the module has
>>added to the stub earlier. The modules are required to loads their
>>configurations according to that policy information and properties they
>>get via MessageContext.
>>
>>Hope this'll help !!
>>
>>Best,
>>Sanka
>>
>>
>>Srinath Perera wrote:
>>
>>
>>>Oops forget to put the prefix, seems I have been too far away
>>
>>>---------- Forwarded message ----------
>>>From: Srinath Perera <he...@gmail.com>
>>>Date: Feb 13, 2006 5:29 PM
>>>Subject: State of WS-Policy?
>>>To: "axis-dev@ws.apache.org" <ax...@ws.apache.org>
>>
>>
>>>Hi All;
>>
>>>I want to ask the state of our policy implementation, and how much the
>>>policy descriptions are bound to modules?
>>
>>>I saw from the code, if there are modules engaged, they are printed
>>>out in WSDL as policy, do we support other side, engaging and
>>>configure the
>>>modules according to the WS-Policy information given in Axis2
>>
>>configuration.
>>
>>
>>>I am more interested in having the policy support in the client side,
>>>and I believe it should be WSDL based. Have we done any work on it? If
>>>not I would like to try to do something on the enabling them on the
>>>dynamic client interface (give a wsdl and configure the
>>>ServiceCleint/OperationClient) as a start
>>
>>>I wrote few thoughts and a possible implementation down, I think most
>>>of it is already done. I want to tie the loose threads and use it and
>>>to fix what ever I can. Please comment.
>>
>>>Thanks
>>>Srinath
>>
>>
>>>WS-Policy and Axis2 Modules are kind of parallel, I would view them as
>>>one is abstract representation and other is implementation of the
>>>representation. To build a policy model for Axis2 we need to describe
>>>two scenarios
>>
>>>1) Build a Service, engage Modules and then create a WSDL description.
>>>This is the most natural scenario for the Server side
>>>2) Given a WSDL, extract the Policy and create a Service with modules
>>
>>engaged
>>
>>
>>>The main work we have to do is
>>>1) Provide a mapping from a given type of policy to a specific module,
>>>then hand over handling that policy to module
>>>2) Define the parameter conversion to and from the Policy, we have
>>
>>two options
>>
>>> a) We can define a mapping from policy to the our parameters
>>>in the modules
>>> b) We can use policy segments inside the service.xml file, for
>>>an example for security module
>>
>>
>>>Possible Implementation
>>>=======================
>>> 1) Every module register a name space of the policy it can handle
>>> 2) If we start from Axis2 configuration Modules at engagement
>>
>>receive
>>
>>>the policy directly or via the service. The Policy could be Axis2
>>>parameters or Policy xml segment. Following is example of policy
>>>segment in engagement.
>>
>>> <service name="SecureService">
>>> <engage name="">
>>> <wsp:Policy>
>>> ...............
>>> <sp:SignedSupportingTokens>
>>> <wsp:Policy>
>>> <sp:UsernameToken
>>>sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Once"
>>>/>
>>> </wsp:Policy>
>>> </sp:SignedSupportingTokens>
>>> ..........
>>> </wsp:Policy>
>>> </enagege>
>>> </service>
>>> 3) When a WSDL is found with policy included, a module is called
>>>based on the #1 mapping, and module is able to process the policy and
>>>configure and engage himself
>>
>>
>>>--
>>>============================
>>>Srinath Perera:
>>> http://www.cs.indiana.edu/~hperera/
>>> http://www.bloglines.com/blog/hemapani
>>
>>
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFD9Emt/Hd0ETKdgNIRAt8pAKCHUEYuEBFVQm3oKpcyoBEsZegmLwCeNIPY
ZG7faGkTIQGtew3WZyzwmkc=
=kdgQ
-----END PGP SIGNATURE-----
Re: Fwd:[Axis2] State of WS-Policy?
Posted by Srinath Perera <he...@gmail.com>.
Hi Sanka;
> > I will have a look at the code, and get back. I am really worrid about
> > the ServiceClient level.
> > For an example when I provide a WSDL with policy to the Service
> > Client, It should be configure itself.
> >
> >>From your explanation I think it is easy thing to do. Is there a work
> > done on that aspect?
>
> At this moment it is not supported at ServiceClient level. It'll be
> really cool if the ServiceClient gets auto configured based on the
> policy information it gets via a WSDL. If you like to work on that I'll
> be happy to help you as/if needed.
+1, will have a look .. think I could do it
Thanks
Srinath
Re: Fwd:[Axis2] State of WS-Policy?
Posted by Sanka Samaranayake <ss...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Srinath, All,
Srinath Perera wrote:
> HI Sanka;
>
> Thanks verymuch for detailed explanation!
>
> I will have a look at the code, and get back. I am really worrid about
> the ServiceClient level.
> For an example when I provide a WSDL with policy to the Service
> Client, It should be configure itself.
>
>>>From your explanation I think it is easy thing to do. Is there a work
> done on that aspect?
At this moment it is not supported at ServiceClient level. It'll be
really cool if the ServiceClient gets auto configured based on the
policy information it gets via a WSDL. If you like to work on that I'll
be happy to help you as/if needed.
BTW, for anyone who is a newcomer to WS Policy, there is an introductory
article I worte on WS Policy. You can find it at:
http://www.wso2.net/?q=node/23
Please feel free to send any feedback
Best,
Sanka
>
> Thanks
> Srinath
>
>
>
>
>
>
> On 2/15/06, Eran Chinthaka <ch...@opensource.lk> wrote:
>
>>Good explanation. Can we have this on wiki ?
>>
>>Sanka Samaranayake wrote:
>>
>>
>>>Hi Srinath, all,
>>>
>>>At this point, Axis2 Codegen does support WS Policies at client-side.
>>>
>>>Let me briefly explain how it happens..
>>>
>>>Phase1: (At PolicyEvaluator)
>>>
>>>Codegen engine runs few of its registered extension before it generates
>>>the stub. When PolicyEvalutor (which is a registered Codegen extension)
>>>is initialized it populates a registry of namespaces of supported
>>>policies to module. For instance module foo might have a mapping of
>>>namespace http://test.com/foo which means any primitive assertion which
>>>has this namespace will be processed by this module.
>>>
>>>e.g. <mns:MyAssertion xmlns:mns="http:tests.org/foo">
>>> ...
>>> </mns:MyAssertion>
>>>
>>>In other words the above assertion in a policy will be processed by the
>>>module 'foo'. Those modules are located using the repository-path which
>>>is given as an argument.
>>>
>>>Then at the engagement, effective policy of each operation is calculated
>>>based on policy information declared in the WSDL document. Here we
>>>assumes that effective policy of an operation contains a single
>>>alternative (Multiple policy alternatives are not supported). Then we
>>>split that policy into few other policies such that each policy will
>>>contains primitive assertions belonging to only one namespace
>>>
>>><wsp:Policy> <wsp:Policy> <wsp:Policy> <wsp:Policy>
>>> <a:Foo/> <a:Foo/> <b:Foo/> <c:Bar/>
>>> <a:Bar/> => <a:Bar/> </wsp:Policy> </wsp:Policy>
>>> <b:Foo/> </wsp:Policy>
>>> <c:Bar/>
>>></wsp:Policy>
>>>
>>>Then each policy is given to the appropriate module with an
>>>org.w3c.Element type object to which the module can append any
>>>other elements/attributes it wishes. Those attributes/elements should
>>>resolved to meaningful stub functions via PolicyExtensionTemplate.xsl at
>>>latter point of time.
>>>
>>>For instance depending on the policy, Security module can append
>>><username>, <passwd> elements to the given element as children, which
>>>are later resolved into setUsername(..), setPasswd(..), functions of the
>>>stub. This way a module can add additional methods to the stub which can
>>>be used get specific parameters to the module. Those methods store any
>>>user input in the ServiceClient properties
>>>(ServiceClient.getOptions().putProperty(...)) which can later be access
>>>by the module.
>>>
>>>Phase2: (At MultiLanguageClientEmitter)
>>>
>>>Further, effective policies (based on the WSDL) at appropriate levels
>>>(service level, operation level) are stored as policy strings in the
>>>stub. Few more generic methods are also added to the stub which are used
>>> to evaluate/processing policies at runtime.
>>>
>>>Runtime:
>>>
>>>When a new stub object is created, the policy strings in the stub are
>>>converted into policy objects and merge together to get the effective
>>>policies of each operation. That policy information is stored in the
>>>AxisOperation object which a module can access at later point of time.
>>>
>>>Then based on its policy each AxisOperation is engaged to a set of
>>>modules.
>>>
>>>And when the stub method is invoked, those modules which are engaged to
>>>that AxisOperation, access the policy information for that operation via
>>>AxisOperation object. It can get other information needed from the
>>>MessageContext which are get stored by stub methods which the module has
>>>added to the stub earlier. The modules are required to loads their
>>>configurations according to that policy information and properties they
>>>get via MessageContext.
>>>
>>>Hope this'll help !!
>>>
>>>Best,
>>>Sanka
>>>
>>>
>>>Srinath Perera wrote:
>>>
>>>
>>>>Oops forget to put the prefix, seems I have been too far away
>>>
>>>>---------- Forwarded message ----------
>>>>From: Srinath Perera <he...@gmail.com>
>>>>Date: Feb 13, 2006 5:29 PM
>>>>Subject: State of WS-Policy?
>>>>To: "axis-dev@ws.apache.org" <ax...@ws.apache.org>
>>>
>>>
>>>>Hi All;
>>>
>>>>I want to ask the state of our policy implementation, and how much the
>>>>policy descriptions are bound to modules?
>>>
>>>>I saw from the code, if there are modules engaged, they are printed
>>>>out in WSDL as policy, do we support other side, engaging and
>>>>configure the
>>>>modules according to the WS-Policy information given in Axis2
>>>
>>>configuration.
>>>
>>>
>>>>I am more interested in having the policy support in the client side,
>>>>and I believe it should be WSDL based. Have we done any work on it? If
>>>>not I would like to try to do something on the enabling them on the
>>>>dynamic client interface (give a wsdl and configure the
>>>>ServiceCleint/OperationClient) as a start
>>>
>>>>I wrote few thoughts and a possible implementation down, I think most
>>>>of it is already done. I want to tie the loose threads and use it and
>>>>to fix what ever I can. Please comment.
>>>
>>>>Thanks
>>>>Srinath
>>>
>>>
>>>>WS-Policy and Axis2 Modules are kind of parallel, I would view them as
>>>>one is abstract representation and other is implementation of the
>>>>representation. To build a policy model for Axis2 we need to describe
>>>>two scenarios
>>>
>>>>1) Build a Service, engage Modules and then create a WSDL description.
>>>>This is the most natural scenario for the Server side
>>>>2) Given a WSDL, extract the Policy and create a Service with modules
>>>
>>>engaged
>>>
>>>
>>>>The main work we have to do is
>>>>1) Provide a mapping from a given type of policy to a specific module,
>>>>then hand over handling that policy to module
>>>>2) Define the parameter conversion to and from the Policy, we have
>>>
>>>two options
>>>
>>>> a) We can define a mapping from policy to the our parameters
>>>>in the modules
>>>> b) We can use policy segments inside the service.xml file, for
>>>>an example for security module
>>>
>>>
>>>>Possible Implementation
>>>>=======================
>>>> 1) Every module register a name space of the policy it can handle
>>>> 2) If we start from Axis2 configuration Modules at engagement
>>>
>>>receive
>>>
>>>>the policy directly or via the service. The Policy could be Axis2
>>>>parameters or Policy xml segment. Following is example of policy
>>>>segment in engagement.
>>>
>>>> <service name="SecureService">
>>>> <engage name="">
>>>> <wsp:Policy>
>>>> ...............
>>>> <sp:SignedSupportingTokens>
>>>> <wsp:Policy>
>>>> <sp:UsernameToken
>>>>sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Once"
>>>>/>
>>>> </wsp:Policy>
>>>> </sp:SignedSupportingTokens>
>>>> ..........
>>>> </wsp:Policy>
>>>> </enagege>
>>>> </service>
>>>> 3) When a WSDL is found with policy included, a module is called
>>>>based on the #1 mapping, and module is able to process the policy and
>>>>configure and engage himself
>>>
>>>
>>>>--
>>>>============================
>>>>Srinath Perera:
>>>> http://www.cs.indiana.edu/~hperera/
>>>> http://www.bloglines.com/blog/hemapani
>>>
>>>
>>>
>>
>>
>
>
> --
> ============================
> Srinath Perera:
> http://www.cs.indiana.edu/~hperera/
> http://www.bloglines.com/blog/hemapani
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFD9EjV/Hd0ETKdgNIRAp5JAKCRQR3Cx/yHygShqWTl4mdxo+397QCffi7n
+5FQ6uv/+bH1dLPjCATOAJM=
=CSX5
-----END PGP SIGNATURE-----
Re: Fwd:[Axis2] State of WS-Policy?
Posted by Srinath Perera <he...@gmail.com>.
HI Sanka;
Thanks verymuch for detailed explanation!
I will have a look at the code, and get back. I am really worrid about
the ServiceClient level.
For an example when I provide a WSDL with policy to the Service
Client, It should be configure itself.
>From your explanation I think it is easy thing to do. Is there a work
done on that aspect?
Thanks
Srinath
On 2/15/06, Eran Chinthaka <ch...@opensource.lk> wrote:
> Good explanation. Can we have this on wiki ?
>
> Sanka Samaranayake wrote:
>
> >
> > Hi Srinath, all,
> >
> > At this point, Axis2 Codegen does support WS Policies at client-side.
> >
> > Let me briefly explain how it happens..
> >
> > Phase1: (At PolicyEvaluator)
> >
> > Codegen engine runs few of its registered extension before it generates
> > the stub. When PolicyEvalutor (which is a registered Codegen extension)
> > is initialized it populates a registry of namespaces of supported
> > policies to module. For instance module foo might have a mapping of
> > namespace http://test.com/foo which means any primitive assertion which
> > has this namespace will be processed by this module.
> >
> > e.g. <mns:MyAssertion xmlns:mns="http:tests.org/foo">
> > ...
> > </mns:MyAssertion>
> >
> > In other words the above assertion in a policy will be processed by the
> > module 'foo'. Those modules are located using the repository-path which
> > is given as an argument.
> >
> > Then at the engagement, effective policy of each operation is calculated
> > based on policy information declared in the WSDL document. Here we
> > assumes that effective policy of an operation contains a single
> > alternative (Multiple policy alternatives are not supported). Then we
> > split that policy into few other policies such that each policy will
> > contains primitive assertions belonging to only one namespace
> >
> > <wsp:Policy> <wsp:Policy> <wsp:Policy> <wsp:Policy>
> > <a:Foo/> <a:Foo/> <b:Foo/> <c:Bar/>
> > <a:Bar/> => <a:Bar/> </wsp:Policy> </wsp:Policy>
> > <b:Foo/> </wsp:Policy>
> > <c:Bar/>
> > </wsp:Policy>
> >
> > Then each policy is given to the appropriate module with an
> > org.w3c.Element type object to which the module can append any
> > other elements/attributes it wishes. Those attributes/elements should
> > resolved to meaningful stub functions via PolicyExtensionTemplate.xsl at
> > latter point of time.
> >
> > For instance depending on the policy, Security module can append
> > <username>, <passwd> elements to the given element as children, which
> > are later resolved into setUsername(..), setPasswd(..), functions of the
> > stub. This way a module can add additional methods to the stub which can
> > be used get specific parameters to the module. Those methods store any
> > user input in the ServiceClient properties
> > (ServiceClient.getOptions().putProperty(...)) which can later be access
> > by the module.
> >
> > Phase2: (At MultiLanguageClientEmitter)
> >
> > Further, effective policies (based on the WSDL) at appropriate levels
> > (service level, operation level) are stored as policy strings in the
> > stub. Few more generic methods are also added to the stub which are used
> > to evaluate/processing policies at runtime.
> >
> > Runtime:
> >
> > When a new stub object is created, the policy strings in the stub are
> > converted into policy objects and merge together to get the effective
> > policies of each operation. That policy information is stored in the
> > AxisOperation object which a module can access at later point of time.
> >
> > Then based on its policy each AxisOperation is engaged to a set of
> > modules.
> >
> > And when the stub method is invoked, those modules which are engaged to
> > that AxisOperation, access the policy information for that operation via
> > AxisOperation object. It can get other information needed from the
> > MessageContext which are get stored by stub methods which the module has
> > added to the stub earlier. The modules are required to loads their
> > configurations according to that policy information and properties they
> > get via MessageContext.
> >
> > Hope this'll help !!
> >
> > Best,
> > Sanka
> >
> >
> > Srinath Perera wrote:
> >
> > >Oops forget to put the prefix, seems I have been too far away
> >
> > >---------- Forwarded message ----------
> > >From: Srinath Perera <he...@gmail.com>
> > >Date: Feb 13, 2006 5:29 PM
> > >Subject: State of WS-Policy?
> > >To: "axis-dev@ws.apache.org" <ax...@ws.apache.org>
> >
> >
> > >Hi All;
> >
> > >I want to ask the state of our policy implementation, and how much the
> > >policy descriptions are bound to modules?
> >
> > >I saw from the code, if there are modules engaged, they are printed
> > >out in WSDL as policy, do we support other side, engaging and
> > >configure the
> > >modules according to the WS-Policy information given in Axis2
> > configuration.
> >
> > >I am more interested in having the policy support in the client side,
> > >and I believe it should be WSDL based. Have we done any work on it? If
> > >not I would like to try to do something on the enabling them on the
> > >dynamic client interface (give a wsdl and configure the
> > >ServiceCleint/OperationClient) as a start
> >
> > >I wrote few thoughts and a possible implementation down, I think most
> > >of it is already done. I want to tie the loose threads and use it and
> > >to fix what ever I can. Please comment.
> >
> > >Thanks
> > >Srinath
> >
> >
> > >WS-Policy and Axis2 Modules are kind of parallel, I would view them as
> > >one is abstract representation and other is implementation of the
> > >representation. To build a policy model for Axis2 we need to describe
> > >two scenarios
> >
> > >1) Build a Service, engage Modules and then create a WSDL description.
> > >This is the most natural scenario for the Server side
> > >2) Given a WSDL, extract the Policy and create a Service with modules
> > engaged
> >
> > >The main work we have to do is
> > >1) Provide a mapping from a given type of policy to a specific module,
> > >then hand over handling that policy to module
> > >2) Define the parameter conversion to and from the Policy, we have
> > two options
> > > a) We can define a mapping from policy to the our parameters
> > >in the modules
> > > b) We can use policy segments inside the service.xml file, for
> > >an example for security module
> >
> >
> > >Possible Implementation
> > >=======================
> > > 1) Every module register a name space of the policy it can handle
> > > 2) If we start from Axis2 configuration Modules at engagement
> > receive
> > >the policy directly or via the service. The Policy could be Axis2
> > >parameters or Policy xml segment. Following is example of policy
> > >segment in engagement.
> >
> > > <service name="SecureService">
> > > <engage name="">
> > > <wsp:Policy>
> > > ...............
> > > <sp:SignedSupportingTokens>
> > > <wsp:Policy>
> > > <sp:UsernameToken
> > >sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Once"
> > >/>
> > > </wsp:Policy>
> > > </sp:SignedSupportingTokens>
> > > ..........
> > > </wsp:Policy>
> > > </enagege>
> > > </service>
> > > 3) When a WSDL is found with policy included, a module is called
> > >based on the #1 mapping, and module is able to process the policy and
> > >configure and engage himself
> >
> >
> > >--
> > >============================
> > >Srinath Perera:
> > > http://www.cs.indiana.edu/~hperera/
> > > http://www.bloglines.com/blog/hemapani
> >
> >
> >
>
>
>
--
============================
Srinath Perera:
http://www.cs.indiana.edu/~hperera/
http://www.bloglines.com/blog/hemapani
Re: Fwd:[Axis2] State of WS-Policy?
Posted by Eran Chinthaka <ch...@opensource.lk>.
Good explanation. Can we have this on wiki ?
Sanka Samaranayake wrote:
>
> Hi Srinath, all,
>
> At this point, Axis2 Codegen does support WS Policies at client-side.
>
> Let me briefly explain how it happens..
>
> Phase1: (At PolicyEvaluator)
>
> Codegen engine runs few of its registered extension before it generates
> the stub. When PolicyEvalutor (which is a registered Codegen extension)
> is initialized it populates a registry of namespaces of supported
> policies to module. For instance module foo might have a mapping of
> namespace http://test.com/foo which means any primitive assertion which
> has this namespace will be processed by this module.
>
> e.g. <mns:MyAssertion xmlns:mns="http:tests.org/foo">
> ...
> </mns:MyAssertion>
>
> In other words the above assertion in a policy will be processed by the
> module 'foo'. Those modules are located using the repository-path which
> is given as an argument.
>
> Then at the engagement, effective policy of each operation is calculated
> based on policy information declared in the WSDL document. Here we
> assumes that effective policy of an operation contains a single
> alternative (Multiple policy alternatives are not supported). Then we
> split that policy into few other policies such that each policy will
> contains primitive assertions belonging to only one namespace
>
> <wsp:Policy> <wsp:Policy> <wsp:Policy> <wsp:Policy>
> <a:Foo/> <a:Foo/> <b:Foo/> <c:Bar/>
> <a:Bar/> => <a:Bar/> </wsp:Policy> </wsp:Policy>
> <b:Foo/> </wsp:Policy>
> <c:Bar/>
> </wsp:Policy>
>
> Then each policy is given to the appropriate module with an
> org.w3c.Element type object to which the module can append any
> other elements/attributes it wishes. Those attributes/elements should
> resolved to meaningful stub functions via PolicyExtensionTemplate.xsl at
> latter point of time.
>
> For instance depending on the policy, Security module can append
> <username>, <passwd> elements to the given element as children, which
> are later resolved into setUsername(..), setPasswd(..), functions of the
> stub. This way a module can add additional methods to the stub which can
> be used get specific parameters to the module. Those methods store any
> user input in the ServiceClient properties
> (ServiceClient.getOptions().putProperty(...)) which can later be access
> by the module.
>
> Phase2: (At MultiLanguageClientEmitter)
>
> Further, effective policies (based on the WSDL) at appropriate levels
> (service level, operation level) are stored as policy strings in the
> stub. Few more generic methods are also added to the stub which are used
> to evaluate/processing policies at runtime.
>
> Runtime:
>
> When a new stub object is created, the policy strings in the stub are
> converted into policy objects and merge together to get the effective
> policies of each operation. That policy information is stored in the
> AxisOperation object which a module can access at later point of time.
>
> Then based on its policy each AxisOperation is engaged to a set of
> modules.
>
> And when the stub method is invoked, those modules which are engaged to
> that AxisOperation, access the policy information for that operation via
> AxisOperation object. It can get other information needed from the
> MessageContext which are get stored by stub methods which the module has
> added to the stub earlier. The modules are required to loads their
> configurations according to that policy information and properties they
> get via MessageContext.
>
> Hope this'll help !!
>
> Best,
> Sanka
>
>
> Srinath Perera wrote:
>
> >Oops forget to put the prefix, seems I have been too far away
>
> >---------- Forwarded message ----------
> >From: Srinath Perera <he...@gmail.com>
> >Date: Feb 13, 2006 5:29 PM
> >Subject: State of WS-Policy?
> >To: "axis-dev@ws.apache.org" <ax...@ws.apache.org>
>
>
> >Hi All;
>
> >I want to ask the state of our policy implementation, and how much the
> >policy descriptions are bound to modules?
>
> >I saw from the code, if there are modules engaged, they are printed
> >out in WSDL as policy, do we support other side, engaging and
> >configure the
> >modules according to the WS-Policy information given in Axis2
> configuration.
>
> >I am more interested in having the policy support in the client side,
> >and I believe it should be WSDL based. Have we done any work on it? If
> >not I would like to try to do something on the enabling them on the
> >dynamic client interface (give a wsdl and configure the
> >ServiceCleint/OperationClient) as a start
>
> >I wrote few thoughts and a possible implementation down, I think most
> >of it is already done. I want to tie the loose threads and use it and
> >to fix what ever I can. Please comment.
>
> >Thanks
> >Srinath
>
>
> >WS-Policy and Axis2 Modules are kind of parallel, I would view them as
> >one is abstract representation and other is implementation of the
> >representation. To build a policy model for Axis2 we need to describe
> >two scenarios
>
> >1) Build a Service, engage Modules and then create a WSDL description.
> >This is the most natural scenario for the Server side
> >2) Given a WSDL, extract the Policy and create a Service with modules
> engaged
>
> >The main work we have to do is
> >1) Provide a mapping from a given type of policy to a specific module,
> >then hand over handling that policy to module
> >2) Define the parameter conversion to and from the Policy, we have
> two options
> > a) We can define a mapping from policy to the our parameters
> >in the modules
> > b) We can use policy segments inside the service.xml file, for
> >an example for security module
>
>
> >Possible Implementation
> >=======================
> > 1) Every module register a name space of the policy it can handle
> > 2) If we start from Axis2 configuration Modules at engagement
> receive
> >the policy directly or via the service. The Policy could be Axis2
> >parameters or Policy xml segment. Following is example of policy
> >segment in engagement.
>
> > <service name="SecureService">
> > <engage name="">
> > <wsp:Policy>
> > ...............
> > <sp:SignedSupportingTokens>
> > <wsp:Policy>
> > <sp:UsernameToken
> >sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Once"
> >/>
> > </wsp:Policy>
> > </sp:SignedSupportingTokens>
> > ..........
> > </wsp:Policy>
> > </enagege>
> > </service>
> > 3) When a WSDL is found with policy included, a module is called
> >based on the #1 mapping, and module is able to process the policy and
> >configure and engage himself
>
>
> >--
> >============================
> >Srinath Perera:
> > http://www.cs.indiana.edu/~hperera/
> > http://www.bloglines.com/blog/hemapani
>
>
>
Re: Fwd:[Axis2] State of WS-Policy?
Posted by Sanka Samaranayake <ss...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Srinath, all,
At this point, Axis2 Codegen does support WS Policies at client-side.
Let me briefly explain how it happens..
Phase1: (At PolicyEvaluator)
Codegen engine runs few of its registered extension before it generates
the stub. When PolicyEvalutor (which is a registered Codegen extension)
is initialized it populates a registry of namespaces of supported
policies to module. For instance module foo might have a mapping of
namespace http://test.com/foo which means any primitive assertion which
has this namespace will be processed by this module.
e.g. <mns:MyAssertion xmlns:mns="http:tests.org/foo">
...
</mns:MyAssertion>
In other words the above assertion in a policy will be processed by the
module 'foo'. Those modules are located using the repository-path which
is given as an argument.
Then at the engagement, effective policy of each operation is calculated
based on policy information declared in the WSDL document. Here we
assumes that effective policy of an operation contains a single
alternative (Multiple policy alternatives are not supported). Then we
split that policy into few other policies such that each policy will
contains primitive assertions belonging to only one namespace
<wsp:Policy> <wsp:Policy> <wsp:Policy> <wsp:Policy>
<a:Foo/> <a:Foo/> <b:Foo/> <c:Bar/>
<a:Bar/> => <a:Bar/> </wsp:Policy> </wsp:Policy>
<b:Foo/> </wsp:Policy>
<c:Bar/>
</wsp:Policy>
Then each policy is given to the appropriate module with an
org.w3c.Element type object to which the module can append any
other elements/attributes it wishes. Those attributes/elements should
resolved to meaningful stub functions via PolicyExtensionTemplate.xsl at
latter point of time.
For instance depending on the policy, Security module can append
<username>, <passwd> elements to the given element as children, which
are later resolved into setUsername(..), setPasswd(..), functions of the
stub. This way a module can add additional methods to the stub which can
be used get specific parameters to the module. Those methods store any
user input in the ServiceClient properties
(ServiceClient.getOptions().putProperty(...)) which can later be access
by the module.
Phase2: (At MultiLanguageClientEmitter)
Further, effective policies (based on the WSDL) at appropriate levels
(service level, operation level) are stored as policy strings in the
stub. Few more generic methods are also added to the stub which are used
to evaluate/processing policies at runtime.
Runtime:
When a new stub object is created, the policy strings in the stub are
converted into policy objects and merge together to get the effective
policies of each operation. That policy information is stored in the
AxisOperation object which a module can access at later point of time.
Then based on its policy each AxisOperation is engaged to a set of modules.
And when the stub method is invoked, those modules which are engaged to
that AxisOperation, access the policy information for that operation via
AxisOperation object. It can get other information needed from the
MessageContext which are get stored by stub methods which the module has
added to the stub earlier. The modules are required to loads their
configurations according to that policy information and properties they
get via MessageContext.
Hope this'll help !!
Best,
Sanka
Srinath Perera wrote:
> Oops forget to put the prefix, seems I have been too far away
>
> ---------- Forwarded message ----------
> From: Srinath Perera <he...@gmail.com>
> Date: Feb 13, 2006 5:29 PM
> Subject: State of WS-Policy?
> To: "axis-dev@ws.apache.org" <ax...@ws.apache.org>
>
>
> Hi All;
>
> I want to ask the state of our policy implementation, and how much the
> policy descriptions are bound to modules?
>
> I saw from the code, if there are modules engaged, they are printed
> out in WSDL as policy, do we support other side, engaging and
> configure the
> modules according to the WS-Policy information given in Axis2 configuration.
>
> I am more interested in having the policy support in the client side,
> and I believe it should be WSDL based. Have we done any work on it? If
> not I would like to try to do something on the enabling them on the
> dynamic client interface (give a wsdl and configure the
> ServiceCleint/OperationClient) as a start
>
> I wrote few thoughts and a possible implementation down, I think most
> of it is already done. I want to tie the loose threads and use it and
> to fix what ever I can. Please comment.
>
> Thanks
> Srinath
>
>
> WS-Policy and Axis2 Modules are kind of parallel, I would view them as
> one is abstract representation and other is implementation of the
> representation. To build a policy model for Axis2 we need to describe
> two scenarios
>
> 1) Build a Service, engage Modules and then create a WSDL description.
> This is the most natural scenario for the Server side
> 2) Given a WSDL, extract the Policy and create a Service with modules engaged
>
> The main work we have to do is
> 1) Provide a mapping from a given type of policy to a specific module,
> then hand over handling that policy to module
> 2) Define the parameter conversion to and from the Policy, we have two options
> a) We can define a mapping from policy to the our parameters
> in the modules
> b) We can use policy segments inside the service.xml file, for
> an example for security module
>
>
> Possible Implementation
> =======================
> 1) Every module register a name space of the policy it can handle
> 2) If we start from Axis2 configuration Modules at engagement receive
> the policy directly or via the service. The Policy could be Axis2
> parameters or Policy xml segment. Following is example of policy
> segment in engagement.
>
> <service name="SecureService">
> <engage name="">
> <wsp:Policy>
> ...............
> <sp:SignedSupportingTokens>
> <wsp:Policy>
> <sp:UsernameToken
> sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Once"
> />
> </wsp:Policy>
> </sp:SignedSupportingTokens>
> ..........
> </wsp:Policy>
> </enagege>
> </service>
> 3) When a WSDL is found with policy included, a module is called
> based on the #1 mapping, and module is able to process the policy and
> configure and engage himself
>
>
> --
> ============================
> Srinath Perera:
> http://www.cs.indiana.edu/~hperera/
> http://www.bloglines.com/blog/hemapani
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFD83AV/Hd0ETKdgNIRAraeAKCK/QViWW6OHewDn1ArOywLZv9AMACfWFHG
F0NGxWnHdbQcslwIyQXEVzA=
=DTcg
-----END PGP SIGNATURE-----
Fwd:[Axis2] State of WS-Policy?
Posted by Srinath Perera <he...@gmail.com>.
Oops forget to put the prefix, seems I have been too far away
---------- Forwarded message ----------
From: Srinath Perera <he...@gmail.com>
Date: Feb 13, 2006 5:29 PM
Subject: State of WS-Policy?
To: "axis-dev@ws.apache.org" <ax...@ws.apache.org>
Hi All;
I want to ask the state of our policy implementation, and how much the
policy descriptions are bound to modules?
I saw from the code, if there are modules engaged, they are printed
out in WSDL as policy, do we support other side, engaging and
configure the
modules according to the WS-Policy information given in Axis2 configuration.
I am more interested in having the policy support in the client side,
and I believe it should be WSDL based. Have we done any work on it? If
not I would like to try to do something on the enabling them on the
dynamic client interface (give a wsdl and configure the
ServiceCleint/OperationClient) as a start
I wrote few thoughts and a possible implementation down, I think most
of it is already done. I want to tie the loose threads and use it and
to fix what ever I can. Please comment.
Thanks
Srinath
WS-Policy and Axis2 Modules are kind of parallel, I would view them as
one is abstract representation and other is implementation of the
representation. To build a policy model for Axis2 we need to describe
two scenarios
1) Build a Service, engage Modules and then create a WSDL description.
This is the most natural scenario for the Server side
2) Given a WSDL, extract the Policy and create a Service with modules engaged
The main work we have to do is
1) Provide a mapping from a given type of policy to a specific module,
then hand over handling that policy to module
2) Define the parameter conversion to and from the Policy, we have two options
a) We can define a mapping from policy to the our parameters
in the modules
b) We can use policy segments inside the service.xml file, for
an example for security module
Possible Implementation
=======================
1) Every module register a name space of the policy it can handle
2) If we start from Axis2 configuration Modules at engagement receive
the policy directly or via the service. The Policy could be Axis2
parameters or Policy xml segment. Following is example of policy
segment in engagement.
<service name="SecureService">
<engage name="">
<wsp:Policy>
...............
<sp:SignedSupportingTokens>
<wsp:Policy>
<sp:UsernameToken
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Once"
/>
</wsp:Policy>
</sp:SignedSupportingTokens>
..........
</wsp:Policy>
</enagege>
</service>
3) When a WSDL is found with policy included, a module is called
based on the #1 mapping, and module is able to process the policy and
configure and engage himself
--
============================
Srinath Perera:
http://www.cs.indiana.edu/~hperera/
http://www.bloglines.com/blog/hemapani