RE: [ws-sx] Issue 42: WS-SC HTTP Binding

["Raepple, Martin" <martin.raepple@sap.com>]

Hi Jan,

I agree that an XML/SOAP load balancer would be a better choice
in such a scenario but since this is a relatively new technology 
I assume that most installed systems today are still HTTP-based
load balancers.

I'm sure that many implementations will solve this issue by using
different mechanisms (e.g. cookies, http headers etc.) and my thinking was to
give a recommendation for a preferred solution by this TC.

I don't feel so strong about this issue and it's up to the TC to
decide. If it violates the charter as Duane mentioned in his mail we
should probably drop it.

- Martin

-----Original Message-----
From: Jan Alexander [mailto:janalex@microsoft.com] 
Sent: Mittwoch, 1. März 2006 04:36
To: Marc Goodner; Raepple, Martin; ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] Issue 42: WS-SC HTTP Binding

Hi Martin,

It is questionable whether the usage of HTTP-level load balancers is
appropriate for ensuring affinity between initiator and receiver that
are sharing state using XML messaging. An XML/SOAP based load balancer
might be a better solution in this case.

This issue is not specific to WS-SX specifications. This same argument
can be used in many other cases. In general, there can be other shared
state maintained between the initiator and receiver that is identified
just inside the SOAP message and has the same issues when used in the
web farm environment. WS-RM sequence state might be one example;
application-level state might be a second example. Are you proposing
that all identifiers representing such shared state should be mapped to
the HTTP headers? What about other transports that do not provide
extensible metadata information (like tcp or udp)?

So far, all WS-* specifications including WS-SecureConversation,
WS-Trust and WS-SecurityPolicy do not rely on underlying transport, they
only use SOAP message-level features. This makes the resulting message
self describing in the sense that you can take the message from the
wire, put it somewhere else (different transport connection, database,
email) and it will still make sense even without the underlying
transport context. The message processing does not require you to
carry-over information to or from underlying layers in order to send or
receive the message properly.

I don't think it will do us any good to introduce such a mapping here,
since it breaks the architectural principle that is behind all WS-SX
specs.

Thanks,
--Jan

-----Original Message-----
From: Marc Goodner [mailto:mgoodner@microsoft.com] 
Sent: Monday, February 27, 2006 10:52 AM
To: martin.raepple@sap.com; ws-sx@lists.oasis-open.org
Subject: [ws-sx] Issue 42: WS-SC HTTP Binding

This is now logged as issue 42.


-----Original Message-----
From: martin.raepple@sap.com [mailto:martin.raepple@sap.com] 
Sent: Monday, February 27, 2006 5:19 AM
To: ws-sx@lists.oasis-open.org
Cc: Marc Goodner
Subject: NEW Issue: WS-SC HTTP Binding

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL
THE ISSUE IS ASSIGNED A NUMBER.  
The issues coordinators will notify the list when that has occurred.

Protocol:  ws-sc

ws-secureconversation-1.3-spec-ed-01-r03-diff.doc

Artifact:  spec

Type:

design

Title:

WS-SC HTTP Binding

Description:

WS-SC introduces the Security Context (SCT) Token which contains a
unique identifier for a shared security context among the context
initiator (requester) and (1 to n) service endpoints. There are
certainly cases where the service endpoint is actually not one system
but a collection of systems (server farm) used for cluster computing.
Server farms are typically co-located with a load balancer which enables
communication between the different servers of the cluster and the users
of the cluster and may perform some type of load balancing

Based on the assumption that the servers in the cluster do not share a
common address space or use any other means to synchronize stateful
resources (such as the security context), the load balancer needs to
send all subsequent requests for the same client to same server which
has access to the previously created security context as part of the SCT
establishment phase (see section 3.3).

The load balancer could certainly look at the
wsse:security/wsc:SecurityContextToken/wsc:Identifier element to
determine the context identifier and route the request to the server
according to same sort of mapping. But this could have an impact of the
overall performance since the load balance has to look inside the
content of the HTTP request and parse the content of the SOAP message.

A much faster approach would be to carry the security context identifier
in the HTTP header. Such an HTTP binding for WS-SC could specify the
relationship between the WS-SC security context and the HTTP header and
should define the name and semantics of new custom HTTP header(s).


Related issues:


Proposed Resolution: