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] > >
