Menu
▾
▴
Re: [ebxmlms-develop] CertResolver questions
|
From: Patrick Y. <kc...@ce...> - 2003-06-11 03:07:08
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body>
<blockquote type="cite"
cite="mid...@s-...">
<div>Example 3:<br>
Assume in ASP mode, messages from client A will be routed to
application A and messages from client B will be routed to application
B.<br>
Suppose that client A creates a message with FromPartyId set to client
A, sign it using client A's key, and does not attach the certificate
in the message. The message is having AppContext of application B. The
attachment of the message is going to screw up application B When the
message comes to Hermes, Hermes will activate CertResolver and use
client A's certificate as it's determined by FromPartyId. The
verification passes and the message routed to application B as it's
determined by AppContext. If application B is not checking the
FromPartyId and the certificate passing up (as you suggested), it is
doomed.<br>
<br>
<span class="589553602-11062003"><font face="Arial" size="2">Do you
mean "message *to* client A will be routed to application A and messages
*to* client B will be routed to application B"?</font></span></div>
<div><span class="589553602-11062003"></span></div>
</blockquote>
<br>
In your definition, you said you have certificate of client A and
client B in your keystore, right? If client A is application A, why you
need their certificate in your keystore? So I guess you mean client A
is the external sender, who sends a message to Hermes. And Hermes will
deliver the message to the client application, right? To avoid
ambiguity, I named the receiving applications as application A and
application B, instead of client A and client B. So normally, client A
will be sending messages to Hermes, and hoping the messages to be
delivered to application A. Client B will be sending messages to
Hermes, and hoping the messages to be delivered to application B.<br>
<br>
<blockquote type="cite"
cite="mid...@s-...">
<div> <span class="589553602-11062003"><font face="Arial" size="2">Why
is the attachment of the message going to screw up application
B? (Does "attachment" mean payload or certificate?) Other than that,
this example is what is supposed to happen, isn't it? I'm not sure
what your example is saying.</font></span></div>
<div><span class="589553602-11062003"></span></div>
</blockquote>
I mean payloads. The payloads generally are business documents. Why the
fake business documents are going to screw up application B is clear.<br>
<br>
My example is saying: if the application is not checking the real
sender and relies only on the routing mechanism of AppContext (which is
likely to happen), it is possible for it to receive a message which
passes signature verification, but the message is from another client
trusted by another application of Hermes.<br>
<br>
<blockquote type="cite"
cite="mid...@s-...">
<div><font face="Arial" size="2"><span class="589553602-11062003">You
still haven't said what's stopping client B from registering
ApplicationContext("*","*","*","*") and receiving client A's (and
everyone else's) messages.</span></font> </div>
</blockquote>
To recap my answer in the "JMS receiver" mail: we should implement a
more sophisticated authorization mechanism to avoid client B from
registering whatever AppContext he wants, including (*,*,*,*). We may
just allow a specifc client to register only a permitted set of
AppContexts.<br>
<br>
Also, in the current wildcard mechanism, messages (A,B,C,D) will be
routed to (A,B,C,D) even if (*,*,*,*) is also registered. The general
rule is a more specific AppContext is of higher priority than a more
general one.<br>
<br>
Regards, -Patrick<br>
<br>
<br>
<br>
<br>
</body>
</html>
|
