You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Venkata Krishnan <fo...@gmail.com> on 2007/11/28 18:05:26 UTC
Policy Handlers ?
Hi,
Sebastien and Raymond, thanks for your responses on the other thread... I
will follow up the issues there one by one. Here I want to discuss about
PolicyHandlers.
Every policyset encapsulate policies that could follow a standard model such
as ws-policy or could follow a custom model as in the case of our
axis2-config-param policy and jdkLogging policy.
Each implementation and binding type could have its own way of interpretting
these policy models and affecting them accordingly in the binding or
implementation. For example the axis2 binding simply injects the ws-policy
into the axis configuration. Some other binding that works with ws-policy
might handle this differently.
This sort of 'policy handling' is what I had initially thought of as
something that can be dealt by PolicyHandler classes. Now I find that how
these classes look and what they do inside it entirely upto the binding and
implementation types including when they are called i.e. during start or
stop of the binding/implementatoin or during invocation of service methods
etc.
Given that the PolicyHandler is getting to be something internal to the
binding or implementation do we ever have to define an SPI for it ? I am
basically questioning the current implementation of defining PolicyHandler
classes in a services sort of file in META-INF directory, loading and
instantiating them, invoking them and so on.
Is there a view-point I am missing here?
Thanks
-Venkat
Re: Policy Handlers ?
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
I have now checked in the calculator-implementation-policies sample to
include the JAAS based authentication. I will try to bring in authorization
as well over this weekend.
I have now distributed the policy hander services files across to the
various policy-* modules. I have changed a bit of my view about policy
handlers as follows:
(a) (b)
PolicyModels -------> PolicyHandlers -------> QoS Infrastructures
(JAAS, Logger, ...)
- The PolicyHandler has two highlevel functions (a) to interpret policy
specifications in various policy models and (b) to interface with QoS
infrastructures to roll out the required quality characteristic such as
security or transactions.
So each policy handler is characterized by the 'type' of the policy model
that it can deal with and the 'QoS' that it can faciliatate. For now I am
using the PolicyModel class for the former and the policy intent name to
denote the latter. The various policy handlers are specified in services
files with these two qualifications.
The JavaPolicyHandlingRuntimeWireProcessor looks up the applicable policyset
for a JavaComponent and figures out the PolicyModel class and the intent
being satisfied. It then loads the corresponding policyhandler.
For now I have included JAAS authentication related things as part of
Tuscany in policy-security. I plan to try and support authorization from
applications i.e. I am planning to bring in authorization into the
calculator-implementation-policies sample without adding anything to
tuscany. This should give a view of how much applications can extend.
If any of you have the time to take a look at these and provide your
thoughts, I'd be grateful :)
- Venkat
On Dec 14, 2007 12:04 AM, Venkata Krishnan <fo...@gmail.com> wrote:
> Hi,
>
> I've tried to add JAAS based 'authentication' to the security policies. I
> apologize for making this mail very long.
>
> Here is a overview of what I did...
>
> - JAAS depends on something called LoginModule and LoginConfiguration. I
> have assumed that this will be taken care of by the applications.
> - Our SCA runtime's role comes in where we perform the authentication
> function. The authentication must interface with the JAAS infrastructure
> and us the JAAS APIs such as the LoginContext.login(). I encapsulated
> this logic into a PolcyHandler which I have created in out policy-security.
> - I have then mapped this handler to a policyset name and this mapping is
> put in the services file of the java-runtime module
> - I then went up to the impl-policies sample, added a jaasAuthentication
> and jaasPolicySet to the definitions.xml. Then I specified
> 'jaasAuthentication' as a requirement for the AddServiceComponent's
> implementation.
>
> I am continuing to use the RuntimeWireProcessor to add the PolicyHandling
> Interceptor for handling polices along the invocation chain. Here are some
> observations...
>
> - The services file that maps policyhandlers to policysets must move out
> of the java-runtime and be defined in the individual policy domain modules..
> such as policy-security or policy-transaction. Sebastien and Raymond has
> already suggested this.
>
> - The policyhanders need to be mapped to 'policy types' and not
> policysets. i.e. every policy handler has two things - 1) the policies (or
> policy structure) that it can make sense out of and 2) the QoS
> infrastructure with which it can interface. For now I could say that
> 'policytypes' are determined by the classnames that capture those policy
> models. But then, assume there is WS-Policy that we may be able to use for
> security and reliability and assume we have a policy handler that can deal
> with WS-Policy models, passing a WS-Policy object to the handler will not
> suffice. We also need to say if this the policy is for security or
> reliability. I hope that the policy handlers can decipher a bit of this by
> studying the model passed.
>
> - there seems to be a need to order the policy-handlers for their
> invocation and also make some conditions around their execution such as...
> should a hander continue to execute if the prev. one has failed and so on.
> In the sample I used, I had the logger and the jaasAuth policies and the
> logger handler continued to execute even when the authenticaion handler had
> failed. Maybe its fine for the logger since the failed ends up getting
> logged, but wonder if this would be ok if we had transaction along with
> authentication.
>
> - finally the user identity, in this just about the user name and password
> need to flow along. Right now I am using a callback handler that returns
> these to the JaasLoginModule. But in a real scenario I'd expect that the
> invocation chains bring along this information. Or alternatively the client
> dumps this sort of info somewhere and the server picks that up. Even there
> the client might have to pass some key to that info.
>
> I'll check this in after making changes to the policyhanlders services
> file.
>
> Thanks
>
>
> On Dec 5, 2007 7:22 AM, Jean-Sebastien Delfino < jsdelfino@apache.org>
> wrote:
>
> > Raymond Feng wrote:
> > > Hi,
> > >
> > > Let's take the transaction policy as an example to understand the
> > > responsibilities of the players.
> > >
> > > Assuming the following intents are declared against the binding or
> > > implementation types, what code are needed to enforce the semantics?
> > >
> > > Intent
> > Binding/Implementation
> > > Type
> > > ----------------------------------
> > > -------------------------------------
> > > 1. managedTransaction.global implementation.java
> > > 2. managedTransaction.global implementation.bpel
> > > 3. suspendsTransaction a reference or service with
> > > binding.sca (local in-VM case)
> > > 4. suspendsTransaction a reference with binding.ws
> > > 5. propagatesTransaction a reference with binding.ws
> > > 6. propagatesTransaction a service with binding.ws
> > >
> > > In case 1 & 2, an transaction interceptor can be added to the
> > invocation.
> > > The interceptor interacts with the transaction manager to make sure a
> > > global
> > > transaction is demarcated before the control hits the component
> > > implementation. The interceptor can be independent of the
> > implementation
> > > types.
> > >
> > > In case 3 & 4, an transaction interceptor can be added to the
> > invocation to
> > > suspend the current transaction before delegating to the next invoker
> > and
> > > resume the transaction after the control is returned.
> > >
> > > In case 5, the binding.ws provider will have to deal with
> > > WS-AtomicTransaction to make sure the transaction context can be
> > propagated
> > > over the SOAP protocol.
> > >
> > > In case 6, if there is an incoming transaction from the WS-AT, the
> > > binding.ws provider will need to import the transaction.
> > >
> > > It seems that the logic that enforces the intents could be a joint
> > > effort of
> > > a policy interceptor and the binding/implementation provider.
> > >
> > > Thanks,
> > > Raymond
> > >
> > > ----- Original Message ----- From: "Venkata Krishnan"
> > > < for.svkrish@gmail.com>
> > > To: <tu...@ws.apache.org>
> > > Sent: Wednesday, November 28, 2007 9:05 AM
> > > Subject: Policy Handlers ?
> > >
> > >
> > >> Hi,
> > >>
> > >> Sebastien and Raymond, thanks for your responses on the other
> > thread... I
> > >> will follow up the issues there one by one. Here I want to discuss
> > about
> > >> PolicyHandlers.
> > >>
> > >> Every policyset encapsulate policies that could follow a standard
> > model
> > >> such
> > >> as ws-policy or could follow a custom model as in the case of our
> > >> axis2-config-param policy and jdkLogging policy.
> > >>
> > >> Each implementation and binding type could have its own way of
> > >> interpretting
> > >> these policy models and affecting them accordingly in the binding or
> > >> implementation. For example the axis2 binding simply injects the
> > >> ws-policy
> > >> into the axis configuration. Some other binding that works with
> > ws-policy
> > >> might handle this differently.
> > >>
> > >> This sort of 'policy handling' is what I had initially thought of as
> > >> something that can be dealt by PolicyHandler classes. Now I find
> > that
> > >> how
> > >> these classes look and what they do inside it entirely upto the
> > binding
> > >> and
> > >> implementation types including when they are called i.e. during start
> > or
> > >> stop of the binding/implementatoin or during invocation of service
> > >> methods
> > >> etc.
> > >>
> > >> Given that the PolicyHandler is getting to be something internal to
> > the
> > >> binding or implementation do we ever have to define an SPI for it ?
> > I am
> > >> basically questioning the current implementation of defining
> > >> PolicyHandler
> > >> classes in a services sort of file in META-INF directory, loading and
> >
> > >> instantiating them, invoking them and so on.
> > >>
> > >> Is there a view-point I am missing here?
> > >>
> > >> Thanks
> > >> -Venkat
> > >>
> > >
> >
> > I think I share your concern with PolicyHandlers.
> >
> > I'm tempted by Raymond's idea of a "joint effort of a policy interceptor
> > and binding/implementation provider" but cannot see a very compelling
> > use case yet.
> >
> > I'd suggest the following staged approach:
> >
> > 1. Implement the particular policy behavior in the binding or
> > implementation code (with no artificial PolicyHandler SPI)
> >
> > 2. If a binding or implementation needs to execute code in the middle of
> > an invocation chain, put this code in an interceptor (using the existing
> >
> > interceptor SPI). I've not seen a use case for this yet, but I could be
> > surprised :)
> >
> > 3. When/if we find that 3 or 4 implementations or bindings must reuse
> > exactly the same policy code, design an interface, an SPI or whatever is
> >
> > best to address that concrete real use case.
> >
> > --
> > Jean-Sebastien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: Policy Handlers ?
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
I've tried to add JAAS based 'authentication' to the security policies. I
apologize for making this mail very long.
Here is a overview of what I did...
- JAAS depends on something called LoginModule and LoginConfiguration. I
have assumed that this will be taken care of by the applications.
- Our SCA runtime's role comes in where we perform the authentication
function. The authentication must interface with the JAAS infrastructure
and us the JAAS APIs such as the LoginContext.login(). I encapsulated this
logic into a PolcyHandler which I have created in out policy-security.
- I have then mapped this handler to a policyset name and this mapping is
put in the services file of the java-runtime module
- I then went up to the impl-policies sample, added a jaasAuthentication and
jaasPolicySet to the definitions.xml. Then I specified 'jaasAuthentication'
as a requirement for the AddServiceComponent's implementation.
I am continuing to use the RuntimeWireProcessor to add the PolicyHandling
Interceptor for handling polices along the invocation chain. Here are some
observations...
- The services file that maps policyhandlers to policysets must move out of
the java-runtime and be defined in the individual policy domain modules..
such as policy-security or policy-transaction. Sebastien and Raymond has
already suggested this.
- The policyhanders need to be mapped to 'policy types' and not policysets.
i.e. every policy handler has two things - 1) the policies (or policy
structure) that it can make sense out of and 2) the QoS infrastructure with
which it can interface. For now I could say that 'policytypes' are
determined by the classnames that capture those policy models. But then,
assume there is WS-Policy that we may be able to use for security and
reliability and assume we have a policy handler that can deal with WS-Policy
models, passing a WS-Policy object to the handler will not suffice. We also
need to say if this the policy is for security or reliability. I hope that
the policy handlers can decipher a bit of this by studying the model passed.
- there seems to be a need to order the policy-handlers for their invocation
and also make some conditions around their execution such as... should a
hander continue to execute if the prev. one has failed and so on. In the
sample I used, I had the logger and the jaasAuth policies and the logger
handler continued to execute even when the authenticaion handler had
failed. Maybe its fine for the logger since the failed ends up getting
logged, but wonder if this would be ok if we had transaction along with
authentication.
- finally the user identity, in this just about the user name and password
need to flow along. Right now I am using a callback handler that returns
these to the JaasLoginModule. But in a real scenario I'd expect that the
invocation chains bring along this information. Or alternatively the client
dumps this sort of info somewhere and the server picks that up. Even there
the client might have to pass some key to that info.
I'll check this in after making changes to the policyhanlders services
file.
Thanks
On Dec 5, 2007 7:22 AM, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Raymond Feng wrote:
> > Hi,
> >
> > Let's take the transaction policy as an example to understand the
> > responsibilities of the players.
> >
> > Assuming the following intents are declared against the binding or
> > implementation types, what code are needed to enforce the semantics?
> >
> > Intent Binding/Implementation
> > Type
> > ----------------------------------
> > -------------------------------------
> > 1. managedTransaction.global implementation.java
> > 2. managedTransaction.global implementation.bpel
> > 3. suspendsTransaction a reference or service with
> > binding.sca (local in-VM case)
> > 4. suspendsTransaction a reference with binding.ws
> > 5. propagatesTransaction a reference with binding.ws
> > 6. propagatesTransaction a service with binding.ws
> >
> > In case 1 & 2, an transaction interceptor can be added to the
> invocation.
> > The interceptor interacts with the transaction manager to make sure a
> > global
> > transaction is demarcated before the control hits the component
> > implementation. The interceptor can be independent of the implementation
> > types.
> >
> > In case 3 & 4, an transaction interceptor can be added to the invocation
> to
> > suspend the current transaction before delegating to the next invoker
> and
> > resume the transaction after the control is returned.
> >
> > In case 5, the binding.ws provider will have to deal with
> > WS-AtomicTransaction to make sure the transaction context can be
> propagated
> > over the SOAP protocol.
> >
> > In case 6, if there is an incoming transaction from the WS-AT, the
> > binding.ws provider will need to import the transaction.
> >
> > It seems that the logic that enforces the intents could be a joint
> > effort of
> > a policy interceptor and the binding/implementation provider.
> >
> > Thanks,
> > Raymond
> >
> > ----- Original Message ----- From: "Venkata Krishnan"
> > <fo...@gmail.com>
> > To: <tu...@ws.apache.org>
> > Sent: Wednesday, November 28, 2007 9:05 AM
> > Subject: Policy Handlers ?
> >
> >
> >> Hi,
> >>
> >> Sebastien and Raymond, thanks for your responses on the other thread...
> I
> >> will follow up the issues there one by one. Here I want to discuss
> about
> >> PolicyHandlers.
> >>
> >> Every policyset encapsulate policies that could follow a standard model
> >> such
> >> as ws-policy or could follow a custom model as in the case of our
> >> axis2-config-param policy and jdkLogging policy.
> >>
> >> Each implementation and binding type could have its own way of
> >> interpretting
> >> these policy models and affecting them accordingly in the binding or
> >> implementation. For example the axis2 binding simply injects the
> >> ws-policy
> >> into the axis configuration. Some other binding that works with
> ws-policy
> >> might handle this differently.
> >>
> >> This sort of 'policy handling' is what I had initially thought of as
> >> something that can be dealt by PolicyHandler classes. Now I find that
> >> how
> >> these classes look and what they do inside it entirely upto the binding
> >> and
> >> implementation types including when they are called i.e. during start
> or
> >> stop of the binding/implementatoin or during invocation of service
> >> methods
> >> etc.
> >>
> >> Given that the PolicyHandler is getting to be something internal to the
> >> binding or implementation do we ever have to define an SPI for it ? I
> am
> >> basically questioning the current implementation of defining
> >> PolicyHandler
> >> classes in a services sort of file in META-INF directory, loading and
> >> instantiating them, invoking them and so on.
> >>
> >> Is there a view-point I am missing here?
> >>
> >> Thanks
> >> -Venkat
> >>
> >
>
> I think I share your concern with PolicyHandlers.
>
> I'm tempted by Raymond's idea of a "joint effort of a policy interceptor
> and binding/implementation provider" but cannot see a very compelling
> use case yet.
>
> I'd suggest the following staged approach:
>
> 1. Implement the particular policy behavior in the binding or
> implementation code (with no artificial PolicyHandler SPI)
>
> 2. If a binding or implementation needs to execute code in the middle of
> an invocation chain, put this code in an interceptor (using the existing
> interceptor SPI). I've not seen a use case for this yet, but I could be
> surprised :)
>
> 3. When/if we find that 3 or 4 implementations or bindings must reuse
> exactly the same policy code, design an interface, an SPI or whatever is
> best to address that concrete real use case.
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Policy Handlers ?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> Let's take the transaction policy as an example to understand the
> responsibilities of the players.
>
> Assuming the following intents are declared against the binding or
> implementation types, what code are needed to enforce the semantics?
>
> Intent Binding/Implementation
> Type
> ----------------------------------
> -------------------------------------
> 1. managedTransaction.global implementation.java
> 2. managedTransaction.global implementation.bpel
> 3. suspendsTransaction a reference or service with
> binding.sca (local in-VM case)
> 4. suspendsTransaction a reference with binding.ws
> 5. propagatesTransaction a reference with binding.ws
> 6. propagatesTransaction a service with binding.ws
>
> In case 1 & 2, an transaction interceptor can be added to the invocation.
> The interceptor interacts with the transaction manager to make sure a
> global
> transaction is demarcated before the control hits the component
> implementation. The interceptor can be independent of the implementation
> types.
>
> In case 3 & 4, an transaction interceptor can be added to the invocation to
> suspend the current transaction before delegating to the next invoker and
> resume the transaction after the control is returned.
>
> In case 5, the binding.ws provider will have to deal with
> WS-AtomicTransaction to make sure the transaction context can be propagated
> over the SOAP protocol.
>
> In case 6, if there is an incoming transaction from the WS-AT, the
> binding.ws provider will need to import the transaction.
>
> It seems that the logic that enforces the intents could be a joint
> effort of
> a policy interceptor and the binding/implementation provider.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Venkata Krishnan"
> <fo...@gmail.com>
> To: <tu...@ws.apache.org>
> Sent: Wednesday, November 28, 2007 9:05 AM
> Subject: Policy Handlers ?
>
>
>> Hi,
>>
>> Sebastien and Raymond, thanks for your responses on the other thread... I
>> will follow up the issues there one by one. Here I want to discuss about
>> PolicyHandlers.
>>
>> Every policyset encapsulate policies that could follow a standard model
>> such
>> as ws-policy or could follow a custom model as in the case of our
>> axis2-config-param policy and jdkLogging policy.
>>
>> Each implementation and binding type could have its own way of
>> interpretting
>> these policy models and affecting them accordingly in the binding or
>> implementation. For example the axis2 binding simply injects the
>> ws-policy
>> into the axis configuration. Some other binding that works with ws-policy
>> might handle this differently.
>>
>> This sort of 'policy handling' is what I had initially thought of as
>> something that can be dealt by PolicyHandler classes. Now I find that
>> how
>> these classes look and what they do inside it entirely upto the binding
>> and
>> implementation types including when they are called i.e. during start or
>> stop of the binding/implementatoin or during invocation of service
>> methods
>> etc.
>>
>> Given that the PolicyHandler is getting to be something internal to the
>> binding or implementation do we ever have to define an SPI for it ? I am
>> basically questioning the current implementation of defining
>> PolicyHandler
>> classes in a services sort of file in META-INF directory, loading and
>> instantiating them, invoking them and so on.
>>
>> Is there a view-point I am missing here?
>>
>> Thanks
>> -Venkat
>>
>
I think I share your concern with PolicyHandlers.
I'm tempted by Raymond's idea of a "joint effort of a policy interceptor
and binding/implementation provider" but cannot see a very compelling
use case yet.
I'd suggest the following staged approach:
1. Implement the particular policy behavior in the binding or
implementation code (with no artificial PolicyHandler SPI)
2. If a binding or implementation needs to execute code in the middle of
an invocation chain, put this code in an interceptor (using the existing
interceptor SPI). I've not seen a use case for this yet, but I could be
surprised :)
3. When/if we find that 3 or 4 implementations or bindings must reuse
exactly the same policy code, design an interface, an SPI or whatever is
best to address that concrete real use case.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy Handlers ?
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Let's take the transaction policy as an example to understand the
responsibilities of the players.
Assuming the following intents are declared against the binding or
implementation types, what code are needed to enforce the semantics?
Intent Binding/Implementation
Type
---------------------------------- -------------------------------------
1. managedTransaction.global implementation.java
2. managedTransaction.global implementation.bpel
3. suspendsTransaction a reference or service with
binding.sca (local in-VM case)
4. suspendsTransaction a reference with binding.ws
5. propagatesTransaction a reference with binding.ws
6. propagatesTransaction a service with binding.ws
In case 1 & 2, an transaction interceptor can be added to the invocation.
The interceptor interacts with the transaction manager to make sure a global
transaction is demarcated before the control hits the component
implementation. The interceptor can be independent of the implementation
types.
In case 3 & 4, an transaction interceptor can be added to the invocation to
suspend the current transaction before delegating to the next invoker and
resume the transaction after the control is returned.
In case 5, the binding.ws provider will have to deal with
WS-AtomicTransaction to make sure the transaction context can be propagated
over the SOAP protocol.
In case 6, if there is an incoming transaction from the WS-AT, the
binding.ws provider will need to import the transaction.
It seems that the logic that enforces the intents could be a joint effort of
a policy interceptor and the binding/implementation provider.
Thanks,
Raymond
----- Original Message -----
From: "Venkata Krishnan" <fo...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Wednesday, November 28, 2007 9:05 AM
Subject: Policy Handlers ?
> Hi,
>
> Sebastien and Raymond, thanks for your responses on the other thread... I
> will follow up the issues there one by one. Here I want to discuss about
> PolicyHandlers.
>
> Every policyset encapsulate policies that could follow a standard model
> such
> as ws-policy or could follow a custom model as in the case of our
> axis2-config-param policy and jdkLogging policy.
>
> Each implementation and binding type could have its own way of
> interpretting
> these policy models and affecting them accordingly in the binding or
> implementation. For example the axis2 binding simply injects the
> ws-policy
> into the axis configuration. Some other binding that works with ws-policy
> might handle this differently.
>
> This sort of 'policy handling' is what I had initially thought of as
> something that can be dealt by PolicyHandler classes. Now I find that how
> these classes look and what they do inside it entirely upto the binding
> and
> implementation types including when they are called i.e. during start or
> stop of the binding/implementatoin or during invocation of service methods
> etc.
>
> Given that the PolicyHandler is getting to be something internal to the
> binding or implementation do we ever have to define an SPI for it ? I am
> basically questioning the current implementation of defining PolicyHandler
> classes in a services sort of file in META-INF directory, loading and
> instantiating them, invoking them and so on.
>
> Is there a view-point I am missing here?
>
> Thanks
> -Venkat
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org