OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: about message authorization


I think we can distinguish two authorization  issues, the second one being more a way to prevent errors:

 

  1. the general issue of authorizing the processing of a received message according to a P-mode. As established, it is not something a WSS module can do by itself without knowledge about P-modes (or mpfs)  as resources to control. Reuse of existing WSS packages may be tricky or underperforming, as the ebms header processor will have to access a security token to do this authorization (even when using UTP or some token reference scheme). But we can consider this an implementation issue, and assume some access to security credentials by the ebms header processor.
  2. the specific issue of making the PullRequest “robust” in the sense that we need to do more to prevent “inadvertent pulling”. We can’t just rely on flawless MPF management.  A mix-up in allocating MPF ids to different partners will have serious consequences, e.g. pulling a message that was not intended to you (and depriving the legitimate receiver), and unlike a pushed message, there is no additional info in header you can double-check with. There should be a solution that does not involve WSS when security is not otherwise needed (given the issues posed by (1))

 

Proposal for (2):

 

Associate the claimed MPF with “readable” information in a Pull signal, that can be used for a consistency check:

- P-mode associated with a PullRequest may contain – in addition to the MPF - the eb:From that is also associated with this Pull MEP (i.e. generally matching the eb:To of the pulled message).

- a Pull signal claiming this MPF must then also insert an eb:PartyInfo that matches the eb:From associated with this MPF.

- corner case: several eb:From  share same receiving MSH (i.e. different eb:To values in messages to be pulled from the same MPF). Because the role of the eb:From in the pull is just authorization of the MPF – not selection within the MPF - , no need to use all the possible eb:From values – just one that is authorized.

 

-Jacques

                                                              



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]