As
discussed in last conf call, after review and updates with Hamid,
here
is a proposal for Secure pulling, which does not require introduction of
new
concepts such as MSH Id.
Although
the text uses RFC2119 keywords, it does not pretend to be even close to final...
(still
rough, several points need be verified / tighten-up - and how this would
split between the core Pull section and the Security section is TBD.)
Jacques
1. Security of Pull mode
(authentication / authorization)
- A Sending MSH MUST be able
to authenticate a Receiving MSH that sends a PullRequest.
MSH support for this feature
is a requirement, though its use is optional.
Authentication MUST be
achieved in a way that does not depend on the parties that
may be using this MSH.
In other words,
authentication of a Receiving MSH must be possible regardless of the
security requirements
specific to the parties using this MSH. For example, even if these
parties decide to not use
any security for exchanging messages - this could be indicated
by a CPA - it may be decided
that the Receiving MSH they use still needs be authenticated
when doing pulling, like
when sending any other MSH-level signal.
(it must be reminded that
several parties with different security requirements,
may share a same MSH.)
- When authentication is
required for a particular Receiving MSH, it is RECOMMENDED
that the Sending MSH uses
persistent security.
In case a Receiving MSHs is
not able to use persistent security based on XML signatures,
a password-based
authentication MAY be used, e.g. as in the HTTP Basic Access Authentication
scheme [RFC2617]. In that
case a secure communication protocol SHOULD be used.
If a CPA is used that
defines an MSH DeliveryChannel for MSH signals sent from Receiving MSH
to Sending MSH, and when a
secure Pull mode is required, then the tp:Transport element [CPPA2.1] referred
to by this MSH DeliveryChannel MUST contain enough information to
support the authentication
of the Receiving MSH, e.g. by enabling signatures.
The tp:Transport element
MUST include a tp:EndPoint element that matches the Sending MSH
endpoint, with type
attribute = "allPurpose".
- The PullRequest signal
MUST contain an EndPoint element similar to the tp:EndPoint element
defined in the tp:Transport
element [CPPA2.1].
The uri attribute of this
element MUST uniquely identify the Receiving MSH, among all
the Receiving MSHs that may
also send PullRequest signals to the same destination.
When persistent
authentication based on signatures is used, a detached, WSS-compliant signature
[WSS] SHALL be used to sign
the EndPoint element so that the integrity of this element is also
guarateed.
Further requirements are
described in more details in the Security module.
- The processing of a
received PullRequest by a Sending MSH is authorized based on
internal information that
the Sending MSH maintains, that associates a list of
endpoint information about
pre-authorized Receiving MSHs, with the queues these are
allowed to pull from.
2- Operational Context and
scenarios (for illustration)
- When pulling is enabled
between a Sending MSH and a Receiving MSH, messages submitted
to the former MUST be pulled
by the latter according to a FIFO policy, effectively
achieving a queuing
behavior. This queuing behavior between Sending MSH and Receiving MSH
is abstractly referred to as
the S-R-queue. No assumption is made on the
implementation of the
S-R-queue.
- A Sending MSH MUST
associate a received PullRequest signal with an S-R-queue by matching
the tp:Endpoint in the
PullRequest with the endpoint info of the Receiving MSH associated with
this S-R-queue.
- A message that is submitted
to the Sending MSH and intended to a Receiving MSH for which pulling
is enabled, MUST be put in
the related S-R-queue only under the following conditions:
(a) the transport attributes
associated with this message - e.g. as defined in the CPA between
the parties exchanging this
message - are compatible with the transport
attributes defined for
PullRequest signals going the other way - e.g. as defined by the
MSH DeliveryChannel of a
CPA. If that were not the case, an error MUST be raised for this message.
Configuration scenario:
o A Receiving MSH is
configured with the endpoint info of every Sending MSH that it is
authorized to pull messages
from. Such endpoint info may be described in the Transport element
associated with the Default
MSH DeliveryChannel of a CPA.
o Similarly, a Sending MSH
is configured with the endpoint info of every Receiving MSH that
is authorized for pulling.
Run-time scenario:
o The Receiving MSH sends a
PullRequest to a Sending MSH.
o The Sending MSH associates
this PullRequest with the claimed Receiving MSH endpoint,
and therefore with the
claimed S-R-queue. It authenticates the "pulling" endpoint as
specified for this
S-R-queue, typically by validating the signature using the certificate
associated with the
MSH-level transport.
o The Sending MSH sends back
the next message in the S-R-queue over the transport response,
applying the QoS and
security required by teh communication between these two parties,
e.g. as defined in the
DeliveryChannel element of their CPA.