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.

Current Policy Providers

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

Policy Scenarios

Authentication - WS Security

Policy set and sample available

Authentication - Single Sign On

No implementation yet

Decide what format the security token is going to take

JMS
Assume authentication.message is required here
It's likely the security token will travel in a JMS message property so the JMS binding needs to be extended to be able to call out to policy providers in order to authenticate the token and retrieve the Subject. The Token/Subject should then be placed in the Tuscany message context.

WS
How is a security token to be flowed to a web service

If authentication.message is in force then this is going to rely on sessions at the SOAP level and could take a similar approach to the existing ws-security based policies to extract the token from a suitable session header. We should make sure the token is available to external (to axis) authentication code Then we need to push the token and the subject into the Tuscany message context

If authentication.transport is in force then the token needs to be extracted from the transport. We expect the container/Axis stack to do this for us initially and put it in the service context. Again we need to get it from there and push this out to the external (to axis) authentication code. Again we need to push the token and the subject into the Tuscany message context

Both JMS and WS approaches have the same pattern...

1. Perform some binding & policy specific processing to extract the token
2. Perform some deployment specific processing to authenticate the token, i.e. call the identity provider
3. Place the results of these two stages in the message context.

These steps require a closer integration between the bindings and the policy providers than we have currently.

Authentication - HTTP Basic

No implementation yet

Need same capability as described in single sign on to get close to the web service binding and configure the transport (reference side) extract transport context (service side).

Confidentiality - WS Security

Policy set and sample available

Integrity - WS Security

Policy set and sample available