First I'll say: Yes, this is Servlets related - at least the first part...
I thought to do something like the following:
I can concatentate all the parameters I need into a big tokenized String, encrypt it on the http side with the public key. Then on the https side, I use the private key to decrypt the received String, and tokenize and pull out the pieces again. I could also use symmetric enc (one private key).
1) Is this just stupid? What other ways can I solve this problem of wanting to protect/obscure form post data between domains? (this is why I've posted this to Servlets.. perhaps someone can point out the obvious answer I've missed).
Here's where it gets past Servlets a bit...
2) I've never done crypto before, and I'm becoming completely overwhelmed with the amount of effort it seems to take to get the simplest thing to work. I've been able to generate my public and private RSA keys.
Now.. I should be able to use those keys in a Cipher... but I can't get an RSA Cipher. The 'signer' works fine (I took this from a tutorial on digital signatures) but the cipher throws java.security.NoSuchAlgorithmException: Cannot find any provider supporting RSA
Apparently I need a differenet provider than the one that comes baked-in to JDK1.4 . I've been to bouncycastle.org, and then they start advising about security policies, and how to install the JCE provider. ARGH!
Does anyone know of a JDK1.4 built-in encryption algorithm that I can use to generate public/private keys, and the Cipher, and anything else I'd possibly need to encrypt/decrypt a simple String?
It doesn't have to be made of a titanium/steel alloy, it really just has to discourage the slightly bright, but essentially lazy.
Lasse, Thanks! I had forgotten about the Almanac. Code there allowed me to figure out which Cipher algorithms were available.
Colin ... yes, it probably would be. I was hoping to avoid the use of a database though. I was going for 'small as possible' on the ecommerce app (which is currently two JSP pages and 5 classes).
The 'n' apps already have their own database. So to use a database as the "data rendezvous", I have two choices: Do 'n' apps connect to 2 databases each ? (their own, plus the e-commerce database?) or... Does the e-commerce connect to 'n' databases? I think I'd lean towards the last option.
posted 14 years ago
I hear what you are saying. I would be more inclined to have an Web Service in front of the ecommerce payment component. The details of the transaction could be sent back via the service and stored, with cross reference information.
So a two stage payment process with web services...
application 'n' - use web service create transaction web service returns transaction identifier application 'n' calls common ecommerce application component to process with transaction identifier ecommerce application returns pertinent details via the web service
The thought of having the amount to pay embedded in a page which the user has access to doesn't sit well with me... :-)