You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: zip/README
+50-1Lines changed: 50 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -95,8 +95,57 @@ Refer to our Developer's Guide for details <http://apps.cybersource.com/library/
95
95
3. If you make any changes to the AuthSample.java sample, you
96
96
must rebuild the sample before using it. Use the compileSample batch file or
97
97
shell script provided in the sample directory.
98
+
99
+
##Message Level Encryption
100
+
101
+
CyberSource supports Message Level Encryption (MLE) for Simple Order API. Message level encryption conforms to the SOAP Security 1.0 specification published by the OASIS standards group.
102
+
103
+
Authentication Details
104
+
Message level encryption authenticates using the same mechanism as signed SOAP messages. The signature creation involves utilizing the merchants private key which combined with a hash of the message to be signed, can be validated with the merchants certificate and the message which was signed.
105
+
The merchant certificate is included in the SOAP message for both signature and message level encryption. Message level encryption, encrypts a temporary message key for a specific recipient. This is done by encrypting the temporary message key with the recipient’s public certificate. Therefore only the party holding the private key (CyberSource) can decrypt the temporary message key. The merchant sending the request must be a valid merchant for the environment which the message is being processed in. After validating the merchant and retrieving the CyberSource copy of the merchant certificate from our database, these additional authentication steps are performed;
106
+
1. The certificate sent in the message must have valid trust chain with the CyberSource certificate authority as the root signer.
107
+
2. A certificate belonging to the merchant which sent the message must exist within our database, having the exact serial number of the certificate provided.
108
+
3. Our record of the certificate must have a valid start and end date for the transaction time sent.
109
+
4. Our record of the certificate must have a “active” state (ie. Not deactivated by support).
110
+
5. If merchant is reseller, the merchant must allow reseller to act upon their behalf and reseller must be configured as a reseller and the provided merchant must be configured as a merchant of this reseller. Additionally all above authorizations apply.
111
+
112
+
Cryptography Algorithms
113
+
CyberSource utilizes the following algorithms for this implementation. While others may work, the following are validated and recommended. SSL is used for transport security even with encrypted messages. CyberSource asymmetric keys are RSA 2048 keys and therefore your cryptography API should support 2048 bit RSA keys and signatures create with them. The messages are encrypted with a temporary derived key which is used per message. This derived key is AES 256 bit and utilizes CBC blocking mode for encryption. The derived key is encrypted with the recipient ( CyberSource ) public key. The key exchange algorithm used is RSA-OAEP.
114
+
115
+
##Third Party jars
116
+
1.) org.apache.ws.security.wss4j:1.6.19
117
+
The Apache WSS4J project provides a Java implementation of the primary security standards for Web Services, namely the OASIS Web Services Security (WS-Security) specifications
118
+
from the OASIS Web Services Security TC.
119
+
120
+
2.) org.bouncycastle:bcprov-jdk15on:1.55
121
+
This jar contains JCE provider and lightweight API for the Bouncy Castle Cryptography APIs for JDK 1.5 to JDK 1.8.
122
+
123
+
3.) org.apache.santuario:xmlsec:1.5.8
124
+
The XML Security project is aimed at providing implementation of security standards for XML,supports XML-Signature Syntax and Processing,XML Encryption Syntax and Processing,
125
+
and supports XML Digital Signature APIs.
126
+
127
+
4.) org.apache.commons:commons-lang3:3.4
128
+
Apache Commons Lang, a package of Java utility classes for the classes that are in java.lang's hierarchy, or are considered to be so standard as to justify existence in
129
+
java.lang.
130
+
131
+
5.) commons-httpclient:commons-httpclient:3.1
132
+
provides a framework by which new request types (methods) or HTTP extensions can be created easily.
133
+
134
+
6.) commons-logging:commons-logging:jar:1.1.1
135
+
This is getting downloaded as compile time dependency of wss4j:1.6.19.Apache Commons Logging is a thin adapter allowing configurable bridging to other, well known logging
136
+
systems.
137
+
138
+
7.) org.slf4j:slf4j-api:1.7.21 and org.slf4j:slf4j-jcl:1.7.21 .
139
+
slf4j-api is getting used as a dependency for wss4j. Modified to latest version.
140
+
141
+
8.) junit:junit:4.12
142
+
JUnit is a unit testing framework for Java.
143
+
144
+
9.) org.mockito:mockito-all:1.10.19
145
+
Mock objects library for java
146
+
98
147
##Documentation
99
148
100
149
For more information about CyberSource services, see <http://www.cybersource.com/developers/documentation>
101
150
102
-
For all other support needs, see <http://www.cybersource.com/support>
151
+
For all other support needs, see <http://www.cybersource.com/support>
0 commit comments