The net result of associating intents and policysets with model elements is that computed policy sets are associated with bindings and/or implementations. The following is supported to date.
o.a.t.s.policy.logging
Sample: samples/calculator-implementation-policies
Intent:
Tuscany specific
<intent name="logging" constrains="sca:implementation.java"> <description> All messages to and from this implementation must be logged </description> </intent>
Policy Set:
<policySet name="JDKLoggingPolicy" provides="tuscany:logging" appliesTo="sca:implementation.java" xmlns="http://www.osoa.org/xmlns/sca/1.0"> <tuscany:jdkLogger name="calculator"> <logLevel>FINER</logLevel> </tuscany:jdkLogger> </policySet>
Note:
The intent is read from the policy-logging definitions file
Each component is set up with all policy provider factories
During wire creation RuntimeWireImpl adds implementation interceptors and the policy provider factories for the component look at the component/operation to see if an interceptor is required
On invoke the logging takes place
o.a.t.s.policy.security.jaas
Sample: samples/calculator-implementation-policies
Intent:
Tuscany specific
<intent name="jaasAuthentication" constrains="sca:implementation.java"> <description>All invocations to be authenticated</description> </intent>
Policy Set:
<policySet name="JaasPolicy" provides="tuscany:jaasAuthentication" appliesTo="sca:implementation.java" xmlns="http://www.osoa.org/xmlns/sca/1.0"> <tuscany:jaasAuthentication> <tuscany:configurationName>Calculator</tuscany:configurationName> <tuscany:callbackHandler>calculator.security.CalculatorCallbackHandler</tuscany:callbackHandler> </tuscany:jaasAuthentication> </policySet>
Note:
The intent is read from the policy-securitydefinitions file
Each component is set up with all policy provider factories
During wire creation RuntimeWireImpl adds implementation interceptors and the policy provider factories for the component look at the component/operation to see if an interceptor is required
On invoke the JAAS login is performed which relies on a set of Tuscany classes to authenticate the credentials returned from a callback?
The callack though has no message context from which to pull credentials?
Subject is not flowed through to the component
o.a.t.s.policy.security.ws
Sample: samples/helloworld-ws-service-secure
Intent:
SCA Defined
<intent name="authentication" constrains="sca:binding"> <description> Specifying this intent on references requires necessary authentication information to be sent along with outgoing messages. Specifying this intent on service requires incoming messages to be authenticated </description> </intent> <intent name="confidentiality" constrains="sca:binding"> <description> Specifying this intent requires message exchanged to be encrypted </description> </intent> <intent name="integrity" constrains="sca:binding"> <description> Specifying this intent requires message exchanged to be signed </description> </intent>
Policy Set:
Example of policy set that sets up Rampart through config parameters
<sca:policySet name="hw:wsAuthenticationPolicy" provides="authentication" appliesTo="sca:binding.ws" > <tuscany:wsConfigParam> <parameter name="InflowSecurity"> <action> <items>UsernameToken</items> <passwordCallbackClass>helloworld.ServerPWCBHandler</passwordCallbackClass> </action> </parameter> </tuscany:wsConfigParam> </sca:policySet>
Note:
During Axis2ServicProvider.start() the policy handlers are first identified based on the computed policy sets and then the axis configuration is modified using these policy handlers.
o.a.t.s.policy.transaction (the policy implementation part)
TBD