No, AMS was designed specifically to *not* impact existing applications.
This is both a blessing and a curse. On the one hand - it doesn't impact
the applications! Woo hoo! What a blessing!
On the other hand, AMS is *so* transparent that the application has no way
to know anything about the AMS properties of the message, or even if AMS was
enabled when it opened the queue. At the very least the application should
be able to make assertions that a) AMS is enabled; b) queue X has a minimum
protection policy of [signed|sealed]. Ideally, the receiving app should be
able to inquire on AMS properties to obtain the distinguished name of the
sender and the sender's certificate issuer, the policy with which the
message was sent, etc.
For example, when delivering a message the QMgr would populate the AMS
properties residing within a reserved JMS properties folder of the message.
Even if someone were somehow able to insert those properties on sending a
message (for example, I send a non-AMS message with properties indicating it
was signed by Morag), the receiving QMgr would strip them as the message
arrived (throwing an event message and/or error log entry) and then
strip/overlay them when delivering the message based on the type of
protection applied, or absence thereof.
Because when the auditor shows up and asks "how do you know that AMS was
enabled when an adverse event occurred" the only answer today is to describe
all the procedural controls you have (or have not) implemented around MQ
configuration management and log scraping. A much better answer would be
"because if AMS is disabled the application sees it as a fatal error and
shuts down. Here, let me demonstrate." One imagines these assertions
expressed as managed object properties that override class methods, much as
the persistence property works.
Kind regards,
-- T.Rob
T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
+44 (0) 8714 089 546 Voice
https://ioptconsulting.com <https://ioptconsulting.com/>
https://twitter.com/tdotrob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Costa, D. (Damian)
Sent: Tuesday, October 07, 2014 9:15 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: SSL client support
Hi,
Unless of course we're talking about actually message encryption ie Advanced
message security rather than on the connection only..
Which would imply that the apps would need to be able to encrypt and decrypt
the actual payload instead of it just being encrypted on the wire?
My 2c.
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Jefferson Lowrey
Sent: 07 October 2014 02:58 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: SSL client support
Well, nobody has replied to the list on this, probably you got a few replies
to the reply-to.
The answer is, at least as far as I know, that the application should never
require any changes to support MQ SSL connections. Especially if it's JMS.
It's entirely an administrative configuration, in setting up the CCDT or the
SSL environment variables and then the relevant properties on the SVRCONN.
And the keyrings... and ...
Thank you,
Jeff Lowrey
From: Frank Swarbrick
<00000006cad63953-dmarc-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Date: 10/06/2014 04:12 PM
Subject: [MQSERIES] SSL client support
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
_____
I am confused. For an MQ client application to support SSL, are there
actually application level changes that need to be made, and not just client
configuration changes?
This is using JMS, in case that matters.
Thanks,
Frank
_____
<http://listserv.meduniwien.ac.at/archives/mqser-l.html> List Archive -
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> Manage Your
List Settings -
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries> Unsubscribe
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at
<http://www.lsoft.com/resources/manuals.asp> http://www.lsoft.com
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html