[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] WSS questions
See inline …
Wow. Unless I am missing something, the spec is not
clear on the use of the SecurityTokenReference within the eb:SignalMessage.
[Hamid]: Ric, this is not really an implementation problem. It may be a problem for many implementations but not for everybody. I actually have a configuration file that I feed to my security module to tell it exactly what to do (what to encrypt, what to sign, include security token, even tell it the ID to use for it if I want to). So, in theory it is feasible to implement and have it decoupled from the security module (even though it may be hard for certain implementations to do that). However, this is not really the issue here. The SecurityTokenReference within the eb:SignalMessage element was designed to be used ONLY when you don’t have a WSS module (for SMEs who cannot afford to implement WSS), but they can still create a WSS-like element to express the username/password. As I said, we did this for the main reason that we did not want to create a new eb element for username/password (many TC members would object on creating our own eb:Username, eb:Password element).
The thing is that we still have a problem whether WSS is present or not: we need to be able to protect the boxes (pipes) from a non-authorized access by leveraging a username/password mechanism and we want this to be independent from WSS. This is because this authorization for accessing boxes is really different from the authentication done at the WSS module (successfully passing the WSS module does not automatically authorize you to access a given box). Furthermore, in some deployments, the WSS module may be deployed as an XML firewall and the ebMS module itself may be sitting inside the company (it is not always correct to picture an MSH as a black box containing the three modules: security, reliability and ebMS modules. These three modules may as well be distributed).