More work exploring the policy extension model by implementing a token based authentication schema across binding.ws and binding.jm. No authentication is actually performed here. That is left for users to provide their own policy interceptors. However tokens are passed and security Subjects/Principals are created. This exercise has highlighted some awkwardness in the process of building policy implementations. I'll post about this on the mail list.

git-svn-id: http://svn.us.apache.org/repos/asf/tuscany@695374 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 2 insertions, 1 deletions

diff --git a/java/sca/modules/core-spi/src/main/java/org/apache/tuscany/sca/invocation/Message.java b/java/sca/modules/core-spi/src/main/java/org/apache/tuscany/sca/invocation/Message.java
index a727693132..61835217de 100644
--- a/java/sca/modules/core-spi/src/main/java/org/apache/tuscany/sca/invocation/Message.java
+++ b/java/sca/modules/core-spi/src/main/java/org/apache/tuscany/sca/invocation/Message.java
@@ -30,6 +30,7 @@ import org.apache.tuscany.sca.runtime.EndpointReference;
  */
 public interface Message {
     String QOS_CTX_SECURITY_PRINCIPAL = "PRINCIPAL";
+    String QOS_CTX_SECURITY_SUBJECT = "SUBJECT";
 
     /**
      * Returns the body of the message, which will be the payload or parameters associated with the wire
@@ -120,5 +121,5 @@ public interface Message {
      * 
      * @return
      */
-    Map<String, Object> getHeader();
+    Map<String, Object> getHeaders();
 }