You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
|
Dec
(21) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(22) |
Feb
(41) |
Mar
(100) |
Apr
(113) |
May
(70) |
Jun
(89) |
Jul
(79) |
Aug
(17) |
Sep
(16) |
Oct
(9) |
Nov
(7) |
Dec
(22) |
| 2004 |
Jan
(42) |
Feb
(2) |
Mar
(20) |
Apr
(35) |
May
(18) |
Jun
(14) |
Jul
(12) |
Aug
(3) |
Sep
(5) |
Oct
(3) |
Nov
|
Dec
(1) |
| 2005 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(1) |
May
(3) |
Jun
(9) |
Jul
(18) |
Aug
(10) |
Sep
(12) |
Oct
(4) |
Nov
(4) |
Dec
(9) |
| 2006 |
Jan
(10) |
Feb
(2) |
Mar
(3) |
Apr
(3) |
May
(4) |
Jun
(9) |
Jul
(1) |
Aug
(1) |
Sep
(10) |
Oct
(29) |
Nov
(27) |
Dec
(14) |
| 2007 |
Jan
(9) |
Feb
(23) |
Mar
(3) |
Apr
(9) |
May
(21) |
Jun
(24) |
Jul
(21) |
Aug
(22) |
Sep
(11) |
Oct
(5) |
Nov
(3) |
Dec
(4) |
| 2008 |
Jan
(2) |
Feb
(5) |
Mar
(3) |
Apr
(22) |
May
(18) |
Jun
(14) |
Jul
(27) |
Aug
(20) |
Sep
(16) |
Oct
(17) |
Nov
(26) |
Dec
(48) |
| 2009 |
Jan
(37) |
Feb
(14) |
Mar
(39) |
Apr
(66) |
May
(140) |
Jun
(127) |
Jul
(78) |
Aug
(26) |
Sep
(24) |
Oct
(34) |
Nov
(10) |
Dec
(20) |
| 2010 |
Jan
(6) |
Feb
(7) |
Mar
(51) |
Apr
(49) |
May
(71) |
Jun
(57) |
Jul
(42) |
Aug
(53) |
Sep
(21) |
Oct
(4) |
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
(2) |
May
(3) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(1) |
Oct
(2) |
Nov
(2) |
Dec
|
| 2012 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
(3) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2014 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
(4) |
Jun
(2) |
Jul
(4) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(6) |
| 2015 |
Jan
(1) |
Feb
(4) |
Mar
(11) |
Apr
(15) |
May
(12) |
Jun
(13) |
Jul
(7) |
Aug
(7) |
Sep
(5) |
Oct
(3) |
Nov
(5) |
Dec
(15) |
| 2016 |
Jan
(8) |
Feb
(1) |
Mar
(3) |
Apr
(1) |
May
(4) |
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
| 2017 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(6) |
Jul
(15) |
Aug
|
Sep
(1) |
Oct
(3) |
Nov
(3) |
Dec
(7) |
| 2018 |
Jan
(6) |
Feb
(8) |
Mar
(12) |
Apr
(6) |
May
(5) |
Jun
(3) |
Jul
(4) |
Aug
(6) |
Sep
(1) |
Oct
(2) |
Nov
|
Dec
(2) |
| 2019 |
Jan
(5) |
Feb
(5) |
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2021 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2022 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(29) |
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
(4) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Gait B. <gai...@ti...> - 2003-04-14 07:41:16
|
Hi team, signed acks pose some issues on our interoperability tests in Europe. I'm testing against SUN and Seeburger for now. Seeburger is also using = xmlsec 1.0.4, with Xalan and Xerces as spec'd by xmlsec. I've tried with = xalan/xerces from hermes cvs, and with the ones spec'd from xmlsec = 1.0.4. both with the same issues. Don't know about Sun, but theirs is = likely the same as in Asian tests. one issue is with the soap namespace prefix. I've nailed this down to = the fact that hermes passes the doc to xmlsec as a DOM tree, rather than = as a string. When passing this to xmlsec, reserialization uses SAAJ, = which hardcodes 'soap-env' as the prefix, while the others use SOAP. = this causes a digest mismatch. I've solved this (for now) by swapping to = SOAP as the prefix in SAAJ and Hermes, but we need to change this so = that the actual streamed data is passed to XMLSignature in xmlsec. Another is, which is still open is that the SOAP namespace declarations, = which occur originally on the SOAP:envelope are moved to the SOAP:Header = and SOAP:Body elements during C14N. I haven't managed to find or fix = that yet. Any ideas are welcome... One more thing, which may be related, is a nullpointer exception that's = thrown during C14N of an ack from Sun, which has the ds:Reference = elements for the original message. One of those happens to be = <ds:Reference xmlns:ds=3D"....." URI=3D"">. C14N throws an exception in = org\apache\xml\security\c14n\helper\NonNSAttrCompare.java. This happens inside the C14N during the sorting of the attributes. = Tracing revealed that namespace URI and localname resolve to null for = both attribs, and the exception occurs as the compare is deferred to an = equals call of the localnames. thnx, Gait. |
|
From: Ronald v. K. <rv...@ab...> - 2003-04-11 09:44:02
|
If they are in the same webapp things will probably work. It did at least for us in Weblogic 6.1sp3 but that was not with hermes, but with our own application Ronald -----Oorspronkelijk bericht----- Van: Mayne, Peter [mailto:Pet...@ap...] Verzonden: vrijdag 11 april 2003 3:58 Aan: 'ebx...@li...' Onderwerp: RE: [ebxmlms-develop] hermes 1.0 No, I'm using Tomcat 4.1.24-LE. I'm running Hermes and two other webapps that talk with Hermes in the same Tomcat. Hmm, I wonder what would happen if I merged Hermes and my two webapps into a single webapp... PJDM -- Peter Mayne Technology Consultant Spherion Technology Solutions Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602 T: 61 2 62689727 F: 61 2 62689777 > -----Original Message----- > From: Ng Chi Yuen [Cyng] [ mailto:cy...@cs... <mailto:cy...@cs...> ] > Sent: Friday, 11 April 2003 11:52 AM > To: 'ebx...@li...' > Subject: RE: [ebxmlms-develop] hermes 1.0 > > > Hi, > > > Do you have an estimate for when Hermes will work with > AXIS? I'm getting fed > > up with "DataContentHandlerFactory already defined" and "unable to > > internalize message" and all the other Sun bugs in SAAJ et al. > > We have planned that migration to Axis will be our > second issue > for Hermes 1.0. I will be responsible for this part once I finish my > current issue. To play safe, I dare not say the exact time as this > involves significant change in packaging/* while I have other internal > development duties. > > I assume that you are using Tomcat 4.0.4 and thus meet this > "already defined" problem while 4.0.6 or 4.1.x don't. > > Regards, > CY > > -------------------------------------------------------------- > -------------- > Ng Chi Yuen, CY. cy...@ce... > http://www.cecid.hku.hk/ <http://www.cecid.hku.hk/> > Technology Officer, > Centre for > E-Commerce Infrastructure Development, > The University of Hong Kong > -------------------------------------------------------------- > -------------- > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of > TotalView, The debugger > for complex code. Debugging C/C++ programs can leave you > feeling lost and > disoriented. TotalView can help you find your way. Available > on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > ebxmlms-develop mailing list > ebx...@li... > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop <https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop> > The information contained in this email and any attachments to it: (a) may be confidential and if you are not the intended recipient, any interference with, use, disclosure or copying of this material is unauthorised and prohibited; and (b) may contain personal information of the recipient and/or the sender as defined under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to collect, hold and use such information and any personal information contained in a response to this email, for any reasonable purpose in the ordinary course of Spherion's business, including forwarding this email internally or disclosing it to a third party. All personal information collected by Spherion will be handled in accordance with Spherion's Privacy Policy. If you have received this email in error, please notify the sender and delete it. (c) you agree not to employ or arrange employment for any candidate(s) supplied in this email and any attachments without first entering into a contractual agreement with Spherion. You further agree not to divulge any information contained in this document to any person(s) or entities without the express permission of Spherion. |
|
From: Ronald v. K. <rv...@ab...> - 2003-04-11 09:42:38
|
I can already generate ebxml message based on SAAJ from axis (in a hacked way, to see what issues there are). There are however JAXM classes used that are not in axis (like JAXMException, JAXMServlet) So Axis can currently only partly be used. > -----Oorspronkelijk bericht----- > Van: Ng Chi Yuen [Cyng] [mailto:cy...@cs...] > Verzonden: vrijdag 11 april 2003 3:52 > Aan: 'ebx...@li...' > Onderwerp: RE: [ebxmlms-develop] hermes 1.0 > > > Hi, > > > Do you have an estimate for when Hermes will work with > AXIS? I'm getting fed > > up with "DataContentHandlerFactory already defined" and "unable to > > internalize message" and all the other Sun bugs in SAAJ et al. > > We have planned that migration to Axis will be our > second issue > for Hermes 1.0. I will be responsible for this part once I finish my > current issue. To play safe, I dare not say the exact time as this > involves significant change in packaging/* while I have other internal > development duties. > > I assume that you are using Tomcat 4.0.4 and thus meet this > "already defined" problem while 4.0.6 or 4.1.x don't. > > Regards, > CY > > -------------------------------------------------------------- > -------------- > Ng Chi Yuen, CY. cy...@ce... http://www.cecid.hku.hk/ Technology Officer, Centre for E-Commerce Infrastructure Development, The University of Hong Kong ---------------------------------------------------------------------------- ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ ebxmlms-develop mailing list ebx...@li... https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop |
|
From: Ng C. Y. [Cyng] <cy...@cs...> - 2003-04-11 01:51:59
|
Hi,
> Do you have an estimate for when Hermes will work with AXIS? I'm getting fed
> up with "DataContentHandlerFactory already defined" and "unable to
> internalize message" and all the other Sun bugs in SAAJ et al.
We have planned that migration to Axis will be our second issue
for Hermes 1.0. I will be responsible for this part once I finish my
current issue. To play safe, I dare not say the exact time as this
involves significant change in packaging/* while I have other internal
development duties.
I assume that you are using Tomcat 4.0.4 and thus meet this
"already defined" problem while 4.0.6 or 4.1.x don't.
Regards,
CY
----------------------------------------------------------------------------
Ng Chi Yuen, CY. cy...@ce... http://www.cecid.hku.hk/
Technology Officer,
Centre for E-Commerce Infrastructure Development,
The University of Hong Kong
----------------------------------------------------------------------------
|
|
From: Patrick Y. <kc...@ce...> - 2003-04-10 06:32:50
|
<!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>
We have fixed that problem in the latest CVS source.<br>
-Patrick<br>
<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
cite="mid...@s-...">
<meta http-equiv="Content-Type" content="text/html; ">
<title>Message</title>
<meta content="MSHTML 6.00.2800.1141" name="GENERATOR">
<style></style>
<div><span class="586141623-06042003"><font face="Arial" size="2">That's
a backward step. I've been sharing the same config files between
Windows and Linux. This will make things more complicated than they
already are.</font></span></div>
<div> </div>
<div><span class="586141623-06042003"><font face="Arial" size="2">PJDM<br>
</font></span><font size="2">--<br>
Peter Mayne<br>
Technology Consultant<br>
Spherion Technology Solutions<br>
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602<br>
T: 61 2 62689727 F: 61 2 62689777</font> </div>
<blockquote dir="ltr"
style="border-left: 2px solid rgb(0, 0, 0); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div class="OutlookMessageHeader" lang="en-us" dir="ltr"
align="left"><font face="Tahoma" size="2">-----Original Message-----<br>
<b>From:</b> Gait Boxman [<a class="moz-txt-link-freetext" href="mailto:gai...@ti...">mailto:gai...@ti...</a>] <br>
<b>Sent:</b> Friday, 4 April 2003 4:58 PM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a><br>
<b>Subject:</b> Re: [ebxmlms-develop] Nightly build 2003-04-4<br>
<br>
</font></div>
<div><font face="Arial" size="2">got that lately as well. </font></div>
<div><font face="Arial" size="2">The checking on the
MessageRepository setting in the msh.properties.xml is now a lot
stricter. It must be an exact leading string of the file, so make
sure that you use 'C:', backslashes and lowercase for the other
characters in the setting.</font></div>
<div><font face="Arial" size="2">I used to have
'/tmp/ebxmlms/for_polling', but had to change it to
'<a class="moz-txt-link-freetext" href="C:\tmp\ebxmlms\for_polling">C:\tmp\ebxmlms\for_polling</a>' to get things running again. </font></div>
<div> </div>
<div><font face="Arial" size="2">--Gait.</font></div>
<div> </div>
<div>----- Original Message ----- </div>
<blockquote dir="ltr"
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div
style="background: rgb(228, 228, 228) none repeat scroll 0%; -moz-background-clip: initial; -moz-background-inline-policy: initial; -moz-background-origin: initial; font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>From:</b> <a
title="Pet...@ap..."
href="mailto:Pet...@ap...">Mayne, Peter</a> </div>
<div
style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>To:</b> <a
title="ebx...@li..."
href="mailto:%27e...@li...%27">'ebx...@li...'</a> </div>
<div
style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>Sent:</b>
Friday, April 04, 2003 1:19 AM</div>
<div
style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>Subject:</b>
[ebxmlms-develop] Nightly build 2003-04-4</div>
<div><br>
</div>
<p><font size="2">Whenever I try to send a message, I get</font> </p>
<p><font size="2">2003-04-03 23:22:28,330 WARN [Thread-8]:
[10007] File not found -
<a class="moz-txt-link-freetext" href="C:\var\local\hermes\ebxmlms\repository\R0000\rt6lby56lexrvb6NvKY6QA==:">C:\var\local\hermes\ebxmlms\repository\R0000\rt6lby56lexrvb6NvKY6QA==:</a>
EbxmlMessage is not stored in MessageRepository</font></p>
<p><font size="2">in msh.log. When I look in the directory, the
file is there. I cleared the database and directories before I
started using this build.</font></p>
<p><font size="2">The message doesn't get sent through to the
listener. Loopback gets</font> </p>
<p><font size="2">hk.hku.cecid.phoenix.message.handler.RequestException:</font> <br>
<font size="2">Fail to send EbxmlMessage to MessageServiceHandler:</font> <br>
<font size="2"> HTTP response code = 200</font> <br>
<font size="2"> HTTP response message = OK</font> <br>
<font size="2"> at
hk.hku.cecid.phoenix.message.handler.Request.sendMessage(Unknown
Source)</font> <br>
<font size="2"> at
hk.hku.cecid.phoenix.message.handler.Request.send(Unknown Source)</font> <br>
<font size="2"> at LoopBack.run(<a class="moz-txt-link-freetext" href="LoopBack.java:153">LoopBack.java:153</a>)</font> <br>
<font size="2"> at LoopBack.main(<a class="moz-txt-link-freetext" href="LoopBack.java:49">LoopBack.java:49</a>)</font> </p>
<p><font size="2">What time does the nightly build get built?</font> </p>
<p><font size="2">Out of curiosity, what development environment
do you use?</font> </p>
<p><font size="2">PJDM</font> <br>
<font size="2">-- </font><br>
<font size="2">Peter Mayne</font> <br>
<font size="2">Technology Consultant</font> <br>
<font size="2">Spherion Technology Solutions</font> <br>
<font size="2">Level 1, 243 Northbourne Avenue, Lyneham,
ACT, 2602</font> <br>
<font size="2">T: 61 2 62689727 F: 61 2 62689777</font> </p>
<font color="blue" size="3">
<pre>The information contained in this email and any attachments to it:
(a) may be confidential and if you are not the intended recipient, any interference with,
use, disclosure or copying of this material is unauthorised and prohibited; and
(b) may contain personal information of the recipient and/or the sender as defined
under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to
collect, hold and use such information and any personal information contained in a
response to this email, for any reasonable purpose in the ordinary course of
Spherion's
business, including forwarding this email internally or disclosing it to a third party. All
personal information collected by Spherion will be handled in accordance with
Spherion's Privacy Policy. If you have received this email in error, please notify the
sender and delete it.
(c) you agree not to employ or arrange employment for any candidate(s) supplied in
this email and any attachments without first entering into a contractual agreement with
Spherion. You further agree not to divulge any information contained in this document
to any person(s) or entities without the express permission of Spherion.
</pre>
</font></blockquote>
</blockquote>
</blockquote>
</body>
</html>
|
|
From: Ng C. Y. [Cyng] <cy...@cs...> - 2003-04-08 02:22:30
|
Hi,
> I can't see any obvious way of adding a role to a reference when adding
> attachments. Can someone throw me a hint?
After addPayloadContainer(), you can call EbxmlMessage.getManifest()
with which you can getReferences() and setRole() one by one. Convenient
methods may be added in future.
Regards,
CY
----------------------------------------------------------------------------
Ng Chi Yuen, CY. cy...@ce... http://www.cecid.hku.hk/
Technology Officer,
Centre for E-Commerce Infrastructure Development,
The University of Hong Kong
----------------------------------------------------------------------------
|
|
From: Ronald v. K. <rv...@ab...> - 2003-04-07 10:40:40
|
I agree with this order, and with session info as well. SAML based authentication would be possible then as well. Embedded webserver is nice in some instances, but since tomcat is not that heavy, embedding tomcat (see the site how to do that) is an option, but just running it inside tomcat and making use of all the features it has regarding certificates etc. sound better to me. But he... that's just me Ronald Mayne, Peter probeerde het volgende duidelijk te maken op 07-04-03 07:15: > I'd modify "client authentication remote user passing" to "session > information passing". Including all session information (HTTP headers, > time of connection, etc as well as remote user/host/address, and the > equivalent for SMTP) allows for uses in the future that we don't think > of right now. > > If we're adding the user as metadata, it can't be too hard to add > everything else as well (can it?). > > My personal priority order would be > > 1 session information passing > 2 AXIS (no more Sun bugs) > 3 client certificate authentication > 4 embedded web server > > PJDM > -- > Peter Mayne > Technology Consultant > Spherion Technology Solutions > Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602 > T: 61 2 62689727 F: 61 2 62689777 > > -----Original Message----- > *From:* Patrick Yee [mailto:kc...@ce...] > *Sent:* Monday, 7 April 2003 2:52 PM > *To:* ebx...@so... > *Subject:* [ebxmlms-develop] hermes 1.0 > > Now, Hermes development is turning to version pre-1.0. We are > refining the internal package structure and after that we want to > invite you guys to join the development. I think this is valuable > for Hermes development as we don't have time and resources to > address all requirement in Hermes 1.0. Now, at least we have the > following pending items: > > . client certificate authentication > . client authentication remote user passing > . AXIS > . embed web server > > What do you think? > > Regards, -Patrick > > >The information contained in this email and any attachments to it: > >(a) may be confidential and if you are not the intended recipient, any interference with, >use, disclosure or copying of this material is unauthorised and prohibited; and > >(b) may contain personal information of the recipient and/or the sender as defined >under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to >collect, hold and use such information and any personal information contained in a >response to this email, for any reasonable purpose in the ordinary course of >Spherion's >business, including forwarding this email internally or disclosing it to a third party. All >personal information collected by Spherion will be handled in accordance with >Spherion's Privacy Policy. If you have received this email in error, please notify the >sender and delete it. > >(c) you agree not to employ or arrange employment for any candidate(s) supplied in >this email and any attachments without first entering into a contractual agreement with >Spherion. You further agree not to divulge any information contained in this document >to any person(s) or entities without the express permission of Spherion. > > > > |
|
From: Gait B. <gai...@ti...> - 2003-04-07 09:31:20
|
I don't set the envelope when doing verification. But if you don't set =
it, it gets automatically set to 'dsa-sha1' since that is the default.
See diffs below to enable the key-alg loading from the properties file.
diff -r1.148 MessageServiceHandler.java
727a728,729
> private static String keyAlg =3D null;
>=20
822a825
> keyAlg =3D prop.get(Constants.PROPERTY_MSH_KEY_ALGORITHM);
824c827,831
< if (keystorePath.equals("")) {
---
> if (keyAlg.equals("")) {
> keyAlg =3D null;
> }
>=20
> if (keystorePath.equals("")) {
2425c2432,2433
< ackMessage.sign(keystoreAlias, keystorePassword.toCharArray(),
---
> if( keyAlg =3D=3D null ) {
> ackMessage.sign(keystoreAlias, keystorePassword.toCharArray(),
2426a2435,2439
> }
> else {
> ackMessage.sign(keystoreAlias, keystorePassword.toCharArray(),
> keystore, keyAlg);
> }
diff -r1.20 Constants.java
196a197,202
> /**
> * Path to get key algorithm in configuration file
> */
> public static final String PROPERTY_MSH_KEY_ALGORITHM =3D
> "MSH/DigitalSignature/AckSign/Key/Algorithm";
>=20
----- Original Message -----=20
From: Patrick Yee=20
To: ebx...@li...=20
Sent: Monday, April 07, 2003 10:41 AM
Subject: Re: [ebxmlms-develop] signed acknowledgments
Yes, you can pass "dsa-sha1" or "rsa-sha1" as the algorithm parameter =
to the ebxmlMessage.sign() function. And we missed this option when =
signing acks. Adding a property to trigger this behavious sounds good.
Gait, for the verification, there is no need to set the algorithm. =
According to JavaDoc of the XML security library
=
http://nagoya.apache.org/gump/javadoc/xml-security/build/doc/html/api/org=
/apache/xml/security/signature/XMLSignature.html
We can omit the SignatureMethod parameter when constructing the =
XMLSignature object. Since we omit that parameter, so setting any value =
in envelope will have no effect.
BTW, how do you set the envelope when doing verification?
Regards, -Patrick
----- Original Message -----=20
From: Gait Boxman=20
To: ebx...@li...=20
Sent: Friday, April 04, 2003 6:45 PM
Subject: Re: [ebxmlms-develop] signed acknowledgments
Actually, with a bit of hacking I got it to work (I think). BC is =
used from apache...xml/security, where the jce classes are dynamically =
loaded from an Australian ftp site to bypass US export regulations. The =
trick was to pass in the 'rsa-sha1' algorithm parameter to the =
ebxmlMessage.sign function. For acks, I added a property to trigger this =
behaviour ( for signed messages, you can do it from the client =
directly). Funny thing is that verification occurs with the envelope set =
to dsa-sha1 :-), and still works fine. I guess that's because that =
information sits inside the ds:Signature, which is never signed itself, =
and is not used for the verification itself. I don't think I got it =
quite right, yet, bit it seems to work on the loopback...
----- Original Message -----=20
From: Ronald van Kuijk=20
To: 'ebx...@li...'=20
Sent: Friday, April 04, 2003 10:50 AM
Subject: RE: [ebxmlms-develop] signed acknowledgments
from what i've seen the bouncycastle libraries are used in the =
signature process. The rsa algorithms are probably not included due to =
licensing restrictions.
But thats just a wild guess
-----Oorspronkelijk bericht-----
Van: Gait Boxman [mailto:gai...@ti...]
Verzonden: vrijdag 4 april 2003 9:27
Aan: ebx...@li...
Onderwerp: Re: [ebxmlms-develop] signed acknowledgments
One more question: is the limitation to DSA signatures local to =
my machine (i.e. a setup problem on my part), a limitation from Hermes, =
or a limitation from XMLDsig?
I seem to remember we were able to use RSA in the earlier days, =
and they certainly work for SSL...=20
----- Original Message -----=20
From: Gait Boxman=20
To: ebx...@li...=20
Sent: Monday, March 31, 2003 1:56 PM
Subject: [ebxmlms-develop] signed acknowledgments
Hi team,=20
per ebMS2, when signed acknowledgments are requested, the =
acknowledgment must contain the digests of the original (signed or =
unsigned) message. AFAICT, this is currently not implemented. Is there =
an easy way to add it? I've tracked down signing as far as the Apache =
XML security libs, but I was hoping of an easier and faster way to add =
the digests than going through three levels of API's...
thnx, Gait.
|
|
From: Patrick Y. <kc...@ce...> - 2003-04-07 08:41:43
|
Yes, you can pass "dsa-sha1" or "rsa-sha1" as the algorithm parameter to = the ebxmlMessage.sign() function. And we missed this option when signing = acks. Adding a property to trigger this behavious sounds good. Gait, for the verification, there is no need to set the algorithm. = According to JavaDoc of the XML security library http://nagoya.apache.org/gump/javadoc/xml-security/build/doc/html/api/org= /apache/xml/security/signature/XMLSignature.html We can omit the SignatureMethod parameter when constructing the = XMLSignature object. Since we omit that parameter, so setting any value = in envelope will have no effect. BTW, how do you set the envelope when doing verification? Regards, -Patrick ----- Original Message -----=20 From: Gait Boxman=20 To: ebx...@li...=20 Sent: Friday, April 04, 2003 6:45 PM Subject: Re: [ebxmlms-develop] signed acknowledgments Actually, with a bit of hacking I got it to work (I think). BC is used = from apache...xml/security, where the jce classes are dynamically loaded = from an Australian ftp site to bypass US export regulations. The trick = was to pass in the 'rsa-sha1' algorithm parameter to the = ebxmlMessage.sign function. For acks, I added a property to trigger this = behaviour ( for signed messages, you can do it from the client = directly). Funny thing is that verification occurs with the envelope set = to dsa-sha1 :-), and still works fine. I guess that's because that = information sits inside the ds:Signature, which is never signed itself, = and is not used for the verification itself. I don't think I got it = quite right, yet, bit it seems to work on the loopback... ----- Original Message -----=20 From: Ronald van Kuijk=20 To: 'ebx...@li...'=20 Sent: Friday, April 04, 2003 10:50 AM Subject: RE: [ebxmlms-develop] signed acknowledgments from what i've seen the bouncycastle libraries are used in the = signature process. The rsa algorithms are probably not included due to = licensing restrictions. But thats just a wild guess -----Oorspronkelijk bericht----- Van: Gait Boxman [mailto:gai...@ti...] Verzonden: vrijdag 4 april 2003 9:27 Aan: ebx...@li... Onderwerp: Re: [ebxmlms-develop] signed acknowledgments One more question: is the limitation to DSA signatures local to my = machine (i.e. a setup problem on my part), a limitation from Hermes, or = a limitation from XMLDsig? I seem to remember we were able to use RSA in the earlier days, = and they certainly work for SSL...=20 ----- Original Message -----=20 From: Gait Boxman=20 To: ebx...@li...=20 Sent: Monday, March 31, 2003 1:56 PM Subject: [ebxmlms-develop] signed acknowledgments Hi team,=20 per ebMS2, when signed acknowledgments are requested, the = acknowledgment must contain the digests of the original (signed or = unsigned) message. AFAICT, this is currently not implemented. Is there = an easy way to add it? I've tracked down signing as far as the Apache = XML security libs, but I was hoping of an easier and faster way to add = the digests than going through three levels of API's... thnx, Gait. |
|
From: Patrick Y. <kc...@ce...> - 2003-04-07 04:54:46
|
Extracting certificates from signed messagesCurrently we cannot extract = the signature from a signed message. As said in my last message, I agree = that this is necessary for security. We should add this before 1.0. Regards, -Patrick ----- Original Message -----=20 From: Mayne, Peter=20 To: 'ebx...@li...'=20 Sent: Thursday, April 03, 2003 1:26 PM Subject: [ebxmlms-develop] Extracting certificates from signed = messages How do I extract the signatures from a signed message?=20 PJDM=20 --=20 Peter Mayne=20 Technology Consultant=20 Spherion Technology Solutions=20 Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602=20 T: 61 2 62689727 F: 61 2 62689777=20 The information contained in this email and any attachments to it: (a) may be confidential and if you are not the intended recipient, any = interference with,=20 use, disclosure or copying of this material is unauthorised and = prohibited; and (b) may contain personal information of the recipient and/or the sender = as defined=20 under the Privacy Act 1988 (Cth). Consent is hereby given by the = recipient(s) to=20 collect, hold and use such information and any personal information = contained in a=20 response to this email, for any reasonable purpose in the ordinary = course of=20 Spherion's=20 business, including forwarding this email internally or disclosing it to = a third party. All=20 personal information collected by Spherion will be handled in accordance = with=20 Spherion's Privacy Policy. If you have received this email in error, = please notify the=20 sender and delete it. (c) you agree not to employ or arrange employment for any candidate(s) = supplied in=20 this email and any attachments without first entering into a contractual = agreement with=20 Spherion. You further agree not to divulge any information contained in = this document=20 to any person(s) or entities without the express permission of Spherion. |
|
From: Patrick Y. <kc...@ce...> - 2003-04-07 04:52:04
|
Now, Hermes development is turning to version pre-1.0. We are refining = the internal package structure and after that we want to invite you guys = to join the development. I think this is valuable for Hermes development = as we don't have time and resources to address all requirement in Hermes = 1.0. Now, at least we have the following pending items: . client certificate authentication . client authentication remote user passing . AXIS . embed web server What do you think? Regards, -Patrick |
|
From: Patrick Y. <kc...@ce...> - 2003-04-07 04:51:11
|
RE: [ebxmlms-develop] Client authentication remote userI agree. This = feature should be added before 1.0. Regards, -Patrick ----- Original Message -----=20 From: Mayne, Peter=20 To: 'ebx...@li...'=20 Sent: Friday, April 04, 2003 7:59 AM Subject: RE: [ebxmlms-develop] Client authentication remote user My thought is that we have to know who sent the message so we know if = the message is valid. (The more data, the better for the audit trail.) Suppose we deal with partners A and B. Each partner uses client = authentication to connect to our Hermes, and each message is signed. Partner B is naughty, and sends a purchase order that looks like an = order from partner A. The web server will accept the client = authentication, but Hermes ignores it, so we don't know who the message = came from. Some partners (especially smaller shops) might not want to go to the = trouble and expense of signing their messages, and just rely on client = authentication. Or, we might need the remote user for other purposes = (such as Ronald's billing). However, we can't do this at the moment, = because we have no way of finding out who sent the message. Suppose the message is signed. Hermes will then check the digital = signature, which is valid, because the message was correctly signed by = partner B. The message is then passed to the listener, which pulls it = apart and deals with it. However, if we can't look at the certificates = that signed the message (I can't see how to do this in Hermes at the = moment), then we won't know that this message really came from partner = B, and we'll go ahead and process an order that looks like it came from = partner A. Hermes stores the remote address and remote host in its database, but = not the remote user. It would be greatly preferable for metadata such as = remote address/host/user to be passed with the message to the listener, = so then the backend doesn't have to query the Hermes database. Would it be possible to provide for an onMessage(EbxmlMessage, = Metadata) callback, where the Metadata class contains all of the data = (remote host/address/user, MIME headers, etc) relevant to the delivery = of the message? This might mean changing the MessageListener interface = (no big deal in a pre-version 1 product :-). There could be an = alternative MetaMessageListener interface, but that feels ugly. Besides, = if we don't want the extra data, we'll just ignore it. Comments?=20 PJDM=20 --=20 Peter Mayne=20 Technology Consultant=20 Spherion Technology Solutions=20 Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602=20 T: 61 2 62689727 F: 61 2 62689777=20 The information contained in this email and any attachments to it: (a) may be confidential and if you are not the intended recipient, any = interference with,=20 use, disclosure or copying of this material is unauthorised and = prohibited; and (b) may contain personal information of the recipient and/or the sender = as defined=20 under the Privacy Act 1988 (Cth). Consent is hereby given by the = recipient(s) to=20 collect, hold and use such information and any personal information = contained in a=20 response to this email, for any reasonable purpose in the ordinary = course of=20 Spherion's=20 business, including forwarding this email internally or disclosing it to = a third party. All=20 personal information collected by Spherion will be handled in accordance = with=20 Spherion's Privacy Policy. If you have received this email in error, = please notify the=20 sender and delete it. (c) you agree not to employ or arrange employment for any candidate(s) = supplied in=20 this email and any attachments without first entering into a contractual = agreement with=20 Spherion. You further agree not to divulge any information contained in = this document=20 to any person(s) or entities without the express permission of Spherion. |
|
From: Ronald v. K. <rv...@ab...> - 2003-04-06 12:23:50
|
stupid me... i should have known... (it was late, real late when I did this) Ng Chi Yuen [Cyng] probeerde het volgende duidelijk te maken op 05-04-03 15:43: >Hi, > > > >>Is there a reason that e.g. statusRequest and StatusResponse are in the >>HeaderContainer? They belong in a SOAPBody, which is done right, but for >>one reason or another I expected all elements which belong in a SOAPBody >>to be handled by a BodyContainer. There does not exist one, but it would >>improve the api, or am i wrong? >> >> > > The term "HeaderContainer" is borrowed from ebMS2.0 specification >(2.1.3 and Figure 2.1) which means to be a MIME part consisting of a >SOAPMessage. It does not specifically means SOAPHeader. > >Regards, >CY > >---------------------------------------------------------------------------- >Ng Chi Yuen, CY. cy...@ce... http://www.cecid.hku.hk/ >Technology Officer, >Centre for E-Commerce Infrastructure Development, >The University of Hong Kong >---------------------------------------------------------------------------- > > > >------------------------------------------------------- >This SF.net email is sponsored by: ValueWeb: >Dedicated Hosting for just $79/mo with 500 GB of bandwidth! >No other company gives more support or power for your dedicated server >http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ >_______________________________________________ >ebxmlms-develop mailing list >ebx...@li... >https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop > > |
|
From: Ng C. Y. [Cyng] <cy...@cs...> - 2003-04-05 13:43:51
|
Hi,
> Is there a reason that e.g. statusRequest and StatusResponse are in the
> HeaderContainer? They belong in a SOAPBody, which is done right, but for
> one reason or another I expected all elements which belong in a SOAPBody
> to be handled by a BodyContainer. There does not exist one, but it would
> improve the api, or am i wrong?
The term "HeaderContainer" is borrowed from ebMS2.0 specification
(2.1.3 and Figure 2.1) which means to be a MIME part consisting of a
SOAPMessage. It does not specifically means SOAPHeader.
Regards,
CY
----------------------------------------------------------------------------
Ng Chi Yuen, CY. cy...@ce... http://www.cecid.hku.hk/
Technology Officer,
Centre for E-Commerce Infrastructure Development,
The University of Hong Kong
----------------------------------------------------------------------------
|
|
From: Ronald v. K. <rv...@ab...> - 2003-04-05 01:59:04
|
I have been able to fairly easy create a BodyContainer and split the existing HeaderContainer in two, so statusRequest, statusResponse and Manifest are in that container. I adapted EbxmlMessage as well to fit this change. Simpel tests run well, but I did not check complex tests with signatures etc.... Besides a cleaner separation, this makes changing to axis a bit easier, because now we can easilly start using SOAPHeaderElements and SOAPBodyElements instead of just SOAPElements. Everything is nicely separated this way. Probably only the SOAPEnvelop should not be filled in HeaderContainer or BodyContainer, but in an EnvelopContainer (or just in the EbxmlMessage????) Any comments on this? I did it against a cvs-checkout of only a few ours ago (around 00:00 CET) It's 4:00 am now, time to go to sleep.... (I start liking hermes more and more) Ronald Ronald van Kuijk probeerde het volgende duidelijk te maken op 05-04-03 03:09: > Hi, > > Is there a reason that e.g. statusRequest and StatusResponse are in > the HeaderContainer? They belong in a SOAPBody, which is done right, > but for one reason or another I expected all elements which belong in > a SOAPBody to be handled by a BodyContainer. There does not exist one, > but it would improve the api, or am i wrong? > > Regards, > > Ronald > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for > just $79/mo with 500 GB of bandwidth! No other company gives more > support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > ebxmlms-develop mailing list > ebx...@li... > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop |
|
From: Ronald v. K. <rv...@ab...> - 2003-04-05 01:04:13
|
Hi, Is there a reason that e.g. statusRequest and StatusResponse are in the HeaderContainer? They belong in a SOAPBody, which is done right, but for one reason or another I expected all elements which belong in a SOAPBody to be handled by a BodyContainer. There does not exist one, but it would improve the api, or am i wrong? Regards, Ronald |
|
From: Ronald v. K. <rv...@ab...> - 2003-04-04 21:58:40
|
> > I'm still figuring out why the Sun implementation throws an > exception when > > a SOAPHeaderElement is passed to it (via a cast). Then it would be > possible > > to have the ExtensionElement not only return a SOAPElement, but a > > SOAPHeaderElement when the ExtensionElement is an instance of > MessageHeader. > > This is also a good idea. Maybe, I should be more precise in > ExtensionElementImpl, i.e., the construction of ExtensionElementImpl > should > call addHeaderElement() and addBodyElement() instead of > SOAPFactory.createElement(). > Hm..... question: You don't mean that these should be IN the constructor of ExtensionElementImpl do you? But the other solutions (in my mind) seem to be a getting a bit 'fabricated' as well. Any suggestions on how to get a simple solution to this? I tried removing all sun saaj/jaxm libraries and there are several classes from the Sun JAXM implementation (what is the status of the specification btw, there are not that many implementations) which are not implemented in AXIS (yet?) These include JAXMServlet, JAXMException, etc) What is your position towards these issues? Ronald |
|
From: Gait B. <gai...@ti...> - 2003-04-04 10:42:58
|
Actually, with a bit of hacking I got it to work (I think). BC is used =
from apache...xml/security, where the jce classes are dynamically loaded =
from an Australian ftp site to bypass US export regulations. The trick =
was to pass in the 'rsa-sha1' algorithm parameter to the =
ebxmlMessage.sign function. For acks, I added a property to trigger this =
behaviour ( for signed messages, you can do it from the client =
directly). Funny thing is that verification occurs with the envelope set =
to dsa-sha1 :-), and still works fine. I guess that's because that =
information sits inside the ds:Signature, which is never signed itself, =
and is not used for the verification itself. I don't think I got it =
quite right, yet, bit it seems to work on the loopback...
----- Original Message -----=20
From: Ronald van Kuijk=20
To: 'ebx...@li...'=20
Sent: Friday, April 04, 2003 10:50 AM
Subject: RE: [ebxmlms-develop] signed acknowledgments
from what i've seen the bouncycastle libraries are used in the =
signature process. The rsa algorithms are probably not included due to =
licensing restrictions.
But thats just a wild guess
-----Oorspronkelijk bericht-----
Van: Gait Boxman [mailto:gai...@ti...]
Verzonden: vrijdag 4 april 2003 9:27
Aan: ebx...@li...
Onderwerp: Re: [ebxmlms-develop] signed acknowledgments
One more question: is the limitation to DSA signatures local to my =
machine (i.e. a setup problem on my part), a limitation from Hermes, or =
a limitation from XMLDsig?
I seem to remember we were able to use RSA in the earlier days, and =
they certainly work for SSL...=20
----- Original Message -----=20
From: Gait Boxman=20
To: ebx...@li...=20
Sent: Monday, March 31, 2003 1:56 PM
Subject: [ebxmlms-develop] signed acknowledgments
Hi team,=20
per ebMS2, when signed acknowledgments are requested, the =
acknowledgment must contain the digests of the original (signed or =
unsigned) message. AFAICT, this is currently not implemented. Is there =
an easy way to add it? I've tracked down signing as far as the Apache =
XML security libs, but I was hoping of an easier and faster way to add =
the digests than going through three levels of API's...
thnx, Gait.
|
|
From: Patrick Y. <kc...@ce...> - 2003-04-04 10:08:56
|
RE: [ebxmlms-develop] Problem using axis with hermesI guess the = bug/tracker/RFE on sourceforge can serve our needs. Bugzilla is good. = But we still prefer to leverage on sourceforge's resource. :-) -Patrick ----- Original Message -----=20 From: Ronald van Kuijk=20 To: 'ebx...@li...'=20 Sent: Thursday, April 03, 2003 7:01 PM Subject: RE: [ebxmlms-develop] Problem using axis with hermes I don't mean to use the bug/tracker to give my requests priority, just = as an add-on to this mailing-list so things are written-down somewhere = and a centralised issue list is available. You could also choose to = implement bugzilla (quite easy to install) on your local host. Works = like a charm. > -----Oorspronkelijk bericht-----=20 > Van: Ng Chi Yuen [Cyng] [mailto:cy...@cs...]=20 > Verzonden: donderdag 3 april 2003 12:43=20 > Aan: 'ebx...@li...'=20 > Onderwerp: RE: [ebxmlms-develop] Problem using axis with hermes=20 >=20 >=20 > Hi,=20 >=20 > > I understand why AXIS throws an exception, but the way they=20 > check the=20 > > instance type isn't a bad thing to do.=20 >=20 > Yeah... it's not a bad thing. I just wonder we may=20 > somehow be tempted=20 > to create a SOAPElement instance directly using one API=20 > method and add it to=20 > SOAPHeader but get exception finally.=20 >=20 >=20 > > I'm still figuring out why the Sun implementation throws an=20 > exception when=20 > > a SOAPHeaderElement is passed to it (via a cast). Then it=20 > would be possible=20 > > to have the ExtensionElement not only return a SOAPElement, but a=20 > > SOAPHeaderElement when the ExtensionElement is an instance=20 > of MessageHeader.=20 >=20 > This is also a good idea. Maybe, I should be more precise in = > ExtensionElementImpl, i.e., the construction of=20 > ExtensionElementImpl should=20 > call addHeaderElement() and addBodyElement() instead of SOAPFactory. = > createElement().=20 >=20 > > If you have more information on your problems with axis, we=20 > can prevent=20 > > doing duplicate work. I'll draw up a list with our problems = tonight=20 > > (CET+2).=20 >=20 > Thanks a lot for your investigation. Please go on.=20 >=20 >=20 > > The bug/tracker thing of SourceForge does not seem to be used.=20 > > Do you guys have another system for this, accessible by=20 > external people?=20 >=20 > You may post to bug/tracker on SF and we will keep a look. = But=20 > due to our limited resources, we may not be able to fulfill=20 > all requests=20 > as promptly as possible. Please don't mind.=20 >=20 > Regards,=20 > CY=20 >=20 > --------------------------------------------------------------=20 > --------------=20 > Ng Chi Yuen, CY. cy...@ce... =20 http://www.cecid.hku.hk/=20 Technology Officer,=20 Centre for E-Commerce Infrastructure Development,=20 The University of Hong Kong=20 = -------------------------------------------------------------------------= ---=20 -------------------------------------------------------=20 This SF.net email is sponsored by: ValueWeb:=20 Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20 No other company gives more support or power for your dedicated server = http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/=20 _______________________________________________=20 ebxmlms-develop mailing list=20 ebx...@li...=20 https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop=20 |
|
From: Patrick Y. <kc...@ce...> - 2003-04-04 10:04:47
|
RE: [ebxmlms-develop] Signed message debuggingYes. Your keystore seems = to have no problem here. -Patrick ----- Original Message -----=20 From: Mayne, Peter=20 To: 'ebx...@li...'=20 Sent: Thursday, April 03, 2003 2:16 PM Subject: RE: [ebxmlms-develop] Signed message debugging ...and it's working again (with my keystore). It seems that Eclipse is = the culprit.=20 If I run it outside Eclipse with a specified classpath, it works fine. = Presumably Eclipse is using the wrong classpath, and things turn out = wrong. The joys of development.=20 PJDM=20 --=20 Peter Mayne=20 Technology Consultant=20 Spherion Technology Solutions=20 Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602=20 T: 61 2 62689727 F: 61 2 62689777=20 The information contained in this email and any attachments to it: (a) may be confidential and if you are not the intended recipient, any = interference with,=20 use, disclosure or copying of this material is unauthorised and = prohibited; and (b) may contain personal information of the recipient and/or the sender = as defined=20 under the Privacy Act 1988 (Cth). Consent is hereby given by the = recipient(s) to=20 collect, hold and use such information and any personal information = contained in a=20 response to this email, for any reasonable purpose in the ordinary = course of=20 Spherion's=20 business, including forwarding this email internally or disclosing it to = a third party. All=20 personal information collected by Spherion will be handled in accordance = with=20 Spherion's Privacy Policy. If you have received this email in error, = please notify the=20 sender and delete it. (c) you agree not to employ or arrange employment for any candidate(s) = supplied in=20 this email and any attachments without first entering into a contractual = agreement with=20 Spherion. You further agree not to divulge any information contained in = this document=20 to any person(s) or entities without the express permission of Spherion. |
|
From: Ronald v. K. <rv...@ab...> - 2003-04-04 08:51:53
|
from what i've seen the bouncycastle libraries are used in the signature process. The rsa algorithms are probably not included due to licensing restrictions. But thats just a wild guess -----Oorspronkelijk bericht----- Van: Gait Boxman [mailto:gai...@ti...] Verzonden: vrijdag 4 april 2003 9:27 Aan: ebx...@li... Onderwerp: Re: [ebxmlms-develop] signed acknowledgments One more question: is the limitation to DSA signatures local to my machine (i.e. a setup problem on my part), a limitation from Hermes, or a limitation from XMLDsig? I seem to remember we were able to use RSA in the earlier days, and they certainly work for SSL... ----- Original Message ----- From: Gait Boxman <mailto:gai...@ti...> To: ebx...@li... <mailto:ebx...@li...> Sent: Monday, March 31, 2003 1:56 PM Subject: [ebxmlms-develop] signed acknowledgments Hi team, per ebMS2, when signed acknowledgments are requested, the acknowledgment must contain the digests of the original (signed or unsigned) message. AFAICT, this is currently not implemented. Is there an easy way to add it? I've tracked down signing as far as the Apache XML security libs, but I was hoping of an easier and faster way to add the digests than going through three levels of API's... thnx, Gait. |
|
From: Ronald v. K. <rv...@ab...> - 2003-04-04 08:49:06
|
For 'normal' circumstances I agree, but in our case customers want additional action to be taken in the process of receiving a message. Thing like message (attachement) conversion from edi to xml and vice-versa, virus scanning, audit-trails etc...We are therefor developing a 'communication hub' and not (only) using the server as an endpoint (that is why we need multi-hop functionality) Using ejb's and many other j2ee specific things(like jms, mdb's, connectionpools, transactions) makes the core of hermes even simpeler but I agree, it is not for the faint-harted. But the same is true for buidling your own connectionpools, transactionmanager, multi-threaded message-processor etc. Maybe hermes one day will be able to support both. I try to make sure the changes we need can live together with the current core, so e.g. a configuration parameter could be to switch hermes into j2ee mode. Ronald -----Oorspronkelijk bericht----- Van: Mayne, Peter [mailto:Pet...@ap...] Verzonden: vrijdag 4 april 2003 2:55 Aan: 'ebx...@li...' Onderwerp: RE: [ebxmlms-develop] Client authentication remote user I'm happy to leave Hermes as a black box, rather than try and put site-specific checking into it. As long as Hermes passes the relevant information to the listener, the listener (or another interface into the backoffice) can do mapping table checks. That way there's a clean break between the MSH black box and the custom processing. However, Hermes causes information loss from the incoming message to the listener, and we need to overcome that. My main objection to EJBs is that they add an extra level of unnecessary complication for many uses, and Hermes runs quite nicely as it is. PJDM -- Peter Mayne Technology Consultant Spherion Technology Solutions Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602 T: 61 2 62689727 F: 61 2 62689777 > -----Original Message----- > From: Ronald van Kuijk [ mailto:rv...@ab... <mailto:rv...@ab...> ] > Sent: Friday, 4 April 2003 10:37 AM > To: ebx...@li... > Subject: Re: [ebxmlms-develop] Client authentication remote user > > > Why I do not know, but i'm not in favor or against either solution. > > Currently we've implemented lots of logic in ejb's (e.g. > billing). They > have access to the userprincipal as well. I can imagine that > that goes a > little to far or is overkill (although JBoss is not that > expensive ;-) ). > > In several articles about security you come across the issues about > combining transport authentication (BA/Cert), with message based > authentication (or persistent authentication like it is called in > ebxml). In our branche e.g. there are companies that collect messages > from other parties and send them to us. The party that signed the > message is not the same as the one that sents the message. We have > mapping tables that check the combination. This is done on > the MSH level > to prevent illegal messages getting into our backoffice. So > we need to > be able to crosscheck both types of authentication. > > We will be looking into using ejb's for certain parts of > hermes, so we > can eventually get around this and use the principal from the > ejb's. For > the moment however, access to the principal in another way is a good > alternative. Again, if others have arguments in favor of one of the > solutions, i won't argue against it (unless it is a really stupid > argument ;-)) > > Ronald The information contained in this email and any attachments to it: (a) may be confidential and if you are not the intended recipient, any interference with, use, disclosure or copying of this material is unauthorised and prohibited; and (b) may contain personal information of the recipient and/or the sender as defined under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to collect, hold and use such information and any personal information contained in a response to this email, for any reasonable purpose in the ordinary course of Spherion's business, including forwarding this email internally or disclosing it to a third party. All personal information collected by Spherion will be handled in accordance with Spherion's Privacy Policy. If you have received this email in error, please notify the sender and delete it. (c) you agree not to employ or arrange employment for any candidate(s) supplied in this email and any attachments without first entering into a contractual agreement with Spherion. You further agree not to divulge any information contained in this document to any person(s) or entities without the express permission of Spherion. |
|
From: Gait B. <gai...@ti...> - 2003-04-04 07:23:41
|
One more question: is the limitation to DSA signatures local to my = machine (i.e. a setup problem on my part), a limitation from Hermes, or = a limitation from XMLDsig? I seem to remember we were able to use RSA in the earlier days, and they = certainly work for SSL...=20 ----- Original Message -----=20 From: Gait Boxman=20 To: ebx...@li...=20 Sent: Monday, March 31, 2003 1:56 PM Subject: [ebxmlms-develop] signed acknowledgments Hi team,=20 per ebMS2, when signed acknowledgments are requested, the = acknowledgment must contain the digests of the original (signed or = unsigned) message. AFAICT, this is currently not implemented. Is there = an easy way to add it? I've tracked down signing as far as the Apache = XML security libs, but I was hoping of an easier and faster way to add = the digests than going through three levels of API's... thnx, Gait. |
|
From: Gait B. <gai...@ti...> - 2003-04-04 06:55:23
|
Nightly build 2003-04-4got that lately as well.=20
The checking on the MessageRepository setting in the msh.properties.xml =
is now a lot stricter. It must be an exact leading string of the file, =
so make sure that you use 'C:', backslashes and lowercase for the other =
characters in the setting.
I used to have '/tmp/ebxmlms/for_polling', but had to change it to =
'C:\tmp\ebxmlms\for_polling' to get things running again.=20
--Gait.
----- Original Message -----=20
From: Mayne, Peter=20
To: 'ebx...@li...'=20
Sent: Friday, April 04, 2003 1:19 AM
Subject: [ebxmlms-develop] Nightly build 2003-04-4
Whenever I try to send a message, I get=20
2003-04-03 23:22:28,330 WARN [Thread-8]: [10007] File not found - =
C:\var\local\hermes\ebxmlms\repository\R0000\rt6lby56lexrvb6NvKY6QA=3D=3D=
: EbxmlMessage is not stored in MessageRepository
in msh.log. When I look in the directory, the file is there. I cleared =
the database and directories before I started using this build.
The message doesn't get sent through to the listener. Loopback gets=20
hk.hku.cecid.phoenix.message.handler.RequestException:=20
Fail to send EbxmlMessage to MessageServiceHandler:=20
HTTP response code =3D 200=20
HTTP response message =3D OK=20
at =
hk.hku.cecid.phoenix.message.handler.Request.sendMessage(Unknown Source) =
at hk.hku.cecid.phoenix.message.handler.Request.send(Unknown =
Source)=20
at LoopBack.run(LoopBack.java:153)=20
at LoopBack.main(LoopBack.java:49)=20
What time does the nightly build get built?=20
Out of curiosity, what development environment do you use?=20
PJDM=20
--=20
Peter Mayne=20
Technology Consultant=20
Spherion Technology Solutions=20
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602=20
T: 61 2 62689727 F: 61 2 62689777=20
The information contained in this email and any attachments to it:
(a) may be confidential and if you are not the intended recipient, any =
interference with,=20
use, disclosure or copying of this material is unauthorised and =
prohibited; and
(b) may contain personal information of the recipient and/or the sender =
as defined=20
under the Privacy Act 1988 (Cth). Consent is hereby given by the =
recipient(s) to=20
collect, hold and use such information and any personal information =
contained in a=20
response to this email, for any reasonable purpose in the ordinary =
course of=20
Spherion's=20
business, including forwarding this email internally or disclosing it to =
a third party. All=20
personal information collected by Spherion will be handled in accordance =
with=20
Spherion's Privacy Policy. If you have received this email in error, =
please notify the=20
sender and delete it.
(c) you agree not to employ or arrange employment for any candidate(s) =
supplied in=20
this email and any attachments without first entering into a contractual =
agreement with=20
Spherion. You further agree not to divulge any information contained in =
this document=20
to any person(s) or entities without the express permission of Spherion.
|
|
From: Ronald v. K. <rv...@ab...> - 2003-04-04 00:31:49
|
Why I do not know, but i'm not in favor or against either solution. Currently we've implemented lots of logic in ejb's (e.g. billing). They have access to the userprincipal as well. I can imagine that that goes a little to far or is overkill (although JBoss is not that expensive ;-) ). In several articles about security you come across the issues about combining transport authentication (BA/Cert), with message based authentication (or persistent authentication like it is called in ebxml). In our branche e.g. there are companies that collect messages from other parties and send them to us. The party that signed the message is not the same as the one that sents the message. We have mapping tables that check the combination. This is done on the MSH level to prevent illegal messages getting into our backoffice. So we need to be able to crosscheck both types of authentication. We will be looking into using ejb's for certain parts of hermes, so we can eventually get around this and use the principal from the ejb's. For the moment however, access to the principal in another way is a good alternative. Again, if others have arguments in favor of one of the solutions, i won't argue against it (unless it is a really stupid argument ;-)) Ronald Mayne, Peter probeerde het volgende duidelijk te maken op 04-04-03 01:59: > My thought is that we have to know who sent the message so we know if > the message is valid. (The more data, the better for the audit trail.) > > Suppose we deal with partners A and B. Each partner uses client > authentication to connect to our Hermes, and each message is signed. > > Partner B is naughty, and sends a purchase order that looks like an > order from partner A. The web server will accept the client > authentication, but Hermes ignores it, so we don't know who the > message came from. > > Some partners (especially smaller shops) might not want to go to the > trouble and expense of signing their messages, and just rely on client > authentication. Or, we might need the remote user for other purposes > (such as Ronald's billing). However, we can't do this at the moment, > because we have no way of finding out who sent the message. > > Suppose the message is signed. Hermes will then check the digital > signature, which is valid, because the message was correctly signed by > partner B. The message is then passed to the listener, which pulls it > apart and deals with it. However, if we can't look at the certificates > that signed the message (I can't see how to do this in Hermes at the > moment), then we won't know that this message really came from partner > B, and we'll go ahead and process an order that looks like it came > from partner A. > > Hermes stores the remote address and remote host in its database, but > not the remote user. It would be greatly preferable for metadata such > as remote address/host/user to be passed with the message to the > listener, so then the backend doesn't have to query the Hermes database. > > Would it be possible to provide for an onMessage(EbxmlMessage, > Metadata) callback, where the Metadata class contains all of the data > (remote host/address/user, MIME headers, etc) relevant to the delivery > of the message? This might mean changing the MessageListener interface > (no big deal in a pre-version 1 product :-). There could be an > alternative MetaMessageListener interface, but that feels ugly. > Besides, if we don't want the extra data, we'll just ignore it. > > Comments? > > PJDM > -- > Peter Mayne > Technology Consultant > Spherion Technology Solutions > Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602 > T: 61 2 62689727 F: 61 2 62689777 > >The information contained in this email and any attachments to it: > >(a) may be confidential and if you are not the intended recipient, any interference with, >use, disclosure or copying of this material is unauthorised and prohibited; and > >(b) may contain personal information of the recipient and/or the sender as defined >under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to >collect, hold and use such information and any personal information contained in a >response to this email, for any reasonable purpose in the ordinary course of >Spherion's >business, including forwarding this email internally or disclosing it to a third party. All >personal information collected by Spherion will be handled in accordance with >Spherion's Privacy Policy. If you have received this email in error, please notify the >sender and delete it. > >(c) you agree not to employ or arrange employment for any candidate(s) supplied in >this email and any attachments without first entering into a contractual agreement with >Spherion. You further agree not to divulge any information contained in this document >to any person(s) or entities without the express permission of Spherion. > > > > |