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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]>
> 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"
> > > < [EMAIL PROTECTED]>
> > > To: <[email protected]>
> > > 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
