If I had any recommendations for customers, tidy up your JDE authentication. Use standards based (not dodgy) products to protect your ERP. Below is how you can use a JWT to log into JDE securely. You just need a way of generating the JWT in the correct format - which is pretty easy. You can see that implementing this method of auth will allow you to embrace a standards based approach to auth. Something like this stands side by side with our myAccess product.
Using oauth (JWT) to
log into JDE
1.1 Introduction
Adopting
authenticate standards is critical for system adoption and security
compliance. JD Edwards since 9.2.3.2 allows you to log into AIS
or HTML using an access_token, which is a JWT.
1.2 Steps
Commands are run from a linux command line:
Note that these steps are done on the web server. You do not necessarily need to do that. When you are done, all you need is the single key.pfx file (pkcs12 format) which contains the private key for decrypting the contents of the JWT. You would use the same file on all of your webservers.
1.2.1
Key generation:
Generate a private key
$ openssl genrsa -out private.pem 4096
Extract
the public key from the private key
$ openssl rsa -in private.pem -out public.pem -pubout
If you try
to insert private and public keys to PKCS12 format without a certificate you
get an error - Server manager needs pkcs12
openssl pkcs12 -export -inkey private.pem -in public.pem -out keys.p12
unable to load certificates
Generate self-signed certificate with aforesaid key for 10 years. This
certificate isn't used for anything as the counterpart is JWK with just public key, no certificate. This is, open SSL needs the cert (fancy
public key)
$ openssl req -key private.pem -new -x509 -days 3650 -subj
"/C=AU/ST=Victoria/O=Fusion5/OU=CNC Gurus/CN=fusion5.com.au" -out
cert.pem
Convert
the above private key and certificate to PKCS12 format - which is what we need
for SM
$
chmod 0400 private.pem
$ openssl pkcs12 -export -inkey private.pem -in cert.pem -out keys.pfx
-name "fusion5oauth"
Check the
keystore:
$ keytool -list -keystore keys.pfx
From <https://ruleoftech.com/2020/generating-jwt-and-jwk-for-information-exchange-between-services>
1.2.2
Test key access
Ensure
jde user can read the cert
sudo
su - jde920
Cat
/tmp/shannon/keys.pfx
/get
a pile of binary rubbish/
1.3 Configure SM for the
instance you want to login with
Goto a webserver (initially) need to see advanced settings and security
section.
Generate
a JWT: Need to use RS256, as I found out after I had generated a different
JWT… Doh! There are other options.
12 Jan 2022 17:10:18,550[WARN][JAVATOKEN]OAuthJWTAuthenticationManager:
getJWTPayload() - JWT token validation failed com.nimbusds.jose.JOSEException:
Unsupported JWS algorithm HS256, must be RS256, RS384, RS512, PS256,
1.3.1
Generate a test JWT
This
is an awesome site for creating a JWT for testing:
This
will load up an example with the correct HEADER.BODY.CERT JWT
Note
that the private key is not copied…
A
couple of things to note:
Firstly,
remember to paste the entire contents of the private and public keys, with
header.
{
"jti": "1234567890", something unique
"prn": "SM00001", your jde username
"admin": true,
"iat": 1642118901, You might need this - https://www.epochconverter.com/
"exp": 1642118901,
"iss": "shannon",
"at_use_nbr": 1 single use
}
Note
that you need the private key to generate the JWT. The private key encrypts the contents so that
they cannot be tampered with in transit.
This
is all about trust. We are trusting the
person with the private key is being VERY good, a good citizen. Because if you get a hold of the certificate
- then you can generate tokens and login as ANYONE!!! The private key is to be treated like a
password.
1.3.2
Now, login to JDE:
Okay!
This
is good reference:
Every Private Key has a corresponding Public Key. The public key is mathematically derived
from the private key. These two keys, together called a "key pair",
can be used for two purposes: Encryption and Signing. For the purposes of
certificates, signing is far more relevant.
A certificate is basically just a public key, which has been signed by
someone else's private key. This forms the basis of public key infrastructure
(PKI), which is explained in the articles linked in the question.
How do Certificates and Private Keys relate? https://security.stackexchange.com/questions/226747/what-is-the-difference-between-a-certificate-and-a-private-key
A certificate is just a "fancy" public key, which is related
to a private key. You can do the same thing with a certificate as you can do
with a public key.
If Bob gets the certificate of Alice, he can encrypt a message for
Alice. Likewise, if Alice publishes some data and signs it with her private
key, Bob can use Alice's certificate to see if it is really from Alice.
What are all those different file types?
- .pem: A .pem is a de-facto file format called Privacy-Enhanced Mail. A PEM file can
contain a lot of different things, such as certificates, private keys,
public keys and lots of other things. A file being in PEM format says
nothing about the content, just like something being Base64-encoded says
nothing about the content.
- .crt, .cer: This is another pseudo-format that is
commonly used to store certificates. These can either be in the PEM or in
the DER format.
- .p12, .pfx: These are interchangable file extensions for
the PKCS#12 format.
Technically, PKCS#12 is the successor to Microsoft's PFX format, but they
have become interchangable. PKCS#12 files are archives for cryptographic
material. Again, what kind of material this contains is completely up to
the user.
Wait, what!?
Yes, .crt, .pem, .pfx and .p12 can all be used to store certificates, public keys and private
keys. From a purely technical standpoint, you can not tell what the semantic
content of any of these files is just by their file extension. If you ever get
confused, don't worry - you're not alone.
However, there are some common conventions that are being followed. .p12 and .pfx files are usually used to store a
certificate together with the private key that corresponds to this certificate.
Likewise, .crt files usually contain single certificates without any related private key
material.
.pem files are wildcards. They can contain anything, and it's not
uncommon to see them used for all different kinds of purposes. Luckily, they
are all plain text, and are prefixed in a human-readable way, such as
-----BEGIN CERTIFICATE-----
MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G
A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y
...
Why would an application not handle a .crt file if it wants a
client certificate?
A certificate is just a public key, and thus by definition public. A
client certificate is no different - just a public key by a person, machine or
other "client", that is signed by some authority.
An application that wants a client certificate usually wants to use that certificate for
something, such as to authenticate the client to a server. In order to do that,
one needs the certificate and the corresponding private key.
So an application should really write "certificate plus private
key", because the certificate alone is not enough to prove one's identity.
It's actually the private key that does it.
To answer vitm's question: As the answer explains, a private key
is always associated with a public key, and a certificate contains a public
key, as well as other information regarding the individual holding the public
key.
If a server program or client program want to use a certificate (e.g. a
web server using a server certificate or a web browser using a client
certificate), they need both the certificate and the private key.
However, that private key is never sent anywhere. The private key is
used mathematically to decrypt messages, which are encrypted with the public
key in the certificate - and to sign messages, which are verified using the
public key in the certificate.
If I only had a certificate, without a public key, then I would not be
able to act as the server or client, to whom the certificate relates to, as I
could not sign messages or decrypt messages.
No comments:
Post a Comment