data security

Please excuse my ignorance if I should know this, but I haven't been able to find it to be documented on the KG or anywhere else...

How secure is a OneWorld XE session? When a user logs on, are his username and password sent in clear text? And are all data transactions sent in clear text? Or is some kind of encryption used for all communication between the fat client and the ES?

Thanks,

Hi John :

As far as I know, OneWorld Xe sessions don't encrypt data neither
on the database nor on the network.
OneWorld is based on an 'open philosophy', it's up to you to add
security layers to protect data traffic (for example, using IPSec).

Sebastian

Doing a little sniffing of my NIC during a JDE session, I have been able to deduce the following. If anyone can verify this, I'd appreciate it.

1. Username/Password authentication is accomplished using NTLMSSP, also known as the NT challenge/response scheme. This is how NT validation is done when connected to a remote NT machine, or an IIS server that requires authentication. So... The username is sent as plain text, but the password is hashed using an mathematical scheme. That's a good thing.

2. All data other than your password, as I suspected, is sent over the network via ODBC as clear text. This could be a bad thing for things like HIPAA!

This is from a reply I got from Sebastian Sajaroff:

Hi John :

As far as I know, OneWorld Xe sessions don't encrypt data neither
on the database nor on the network.
OneWorld is based on an 'open philosophy', it's up to you to add
security layers to protect data traffic (for example, using IPSec).

Sebastian

I don't know of many (any?) Health Care Providers using OneWorld? They are the only ones covered by HIPAA (http://cms.hhs.gov/hipaa/hipaa2/readinesschklst.pdf)

However, if you are required to encrypt the data stream feel free, just don't think that it is reasonable to expect OneWorld, or any other Enterprise Application to do it for you. Those who need to encrypt data know that they need to....and they do. Those that don't know they need to encrypt data usually don't need to.

Nothing personal but it always seems that the possessors of 'sniffers' are the ones who will spend inordinate amounts of time discussing how 'insecure' everything is.

Yeah, yeah...I know that I don't have to partake or even pay attention to such discussions but I wonder why some folks get paid to sit around with a sniffer so they can tell us that ODBC sessions are in plaintext.

Sheesh, "Brother," in a forum like this, where everone is supposed to be professionals helping professionals, I'd expect a little more from another user. But this isn't slashdot, so I'll leave the finger pointing, name calling, and holier-than-thou attitude to lie solely on your side of the conversation. Instead I'll just justify my position.

Why am I concerned with HIPAA? I am a developer (not a JDE developer, a software developer) at a county government site. We have a Department of Human Services that provides money and services to clients. We also have a hospital or two that are part of our goverment. They are using or soon-to-be using OneWorld. Much of this data is of the type covered by HIPAA. So I guess now you can't say that you don't know of any heathcare providers using OneWorld.

"...just don't think that it is reasonable to expect OneWorld, or any other Enterprise Application to do it for you."
Please show me where in my post I claimed that OneWorld, or any other Enterprise Application, should encrypt data. I simply asked if it did; I made no assertions that it should.

"...the ones who spend inordinate amounts of time..."
Again, you read too far between the lines. If you were this interested in picking apart my post, then you should have noticed that my original query and my response came 41 minutes apart. That means that during those 41 minutes I went and downloaded a sniffer, installed it, ran a quick test, took a peak at the data, then posted my results on this forum for the benefit of any others who may have the same concern. 41 minutes. I'm not so sure that counts as an "inordinate amount of time."

"...I wonder why some folks get paid to sit around with a sniffer so they can tell us that ODBC sessions are in plaintext."
Yup, you missed the point again here. Of course it is obvious that ODBC data transfers are sent in plain text. What I was looking for was to see if perhaps JDE set up an SSL socket through which to tunnel the ODBC traffic. What I found was that it does not. I never claimed that it should, mind you, I just wanted to know if it did. I could find no documentation confirming or disconfirming this here, on the KG, or in the printed manuals. And I was asked to find out, so I did.

Thank you, "Brother," for allowing me the opportunity to further dissect my post. I'm sure it will be to the benefit of the JDE community.

Not sure which part of my post you considered "finger pointing, name calling, and holier-than-thou attitude" but I'll just guess you aren't use to peer review.

Since it appears that you are extra sensitive, I'll just leave you alone to benefit the JDE community.

Karma: Positive

There are really two forms of data transport in the system.

There is data going through the OneWorld middleware (JDEBase) to the underlying database driver. In your case this is the Client Access Express driver.

In addition to this there is traffic being sent over the JDENet protocol between client and server. My understanding is that this traffic is encrypted although JDE has never published a statement as to how it is encrypted. (As a side note my understanding is that ERP 9 will be implementing some open security standards such as SSL and Certificates).

OK I lied, I guess there is a third transport, standard Windows Network Filesystem access between the client and the deployment server and between the client and the server where the Media Objects live. (Perhaps on the deployment server as well.)

I would agree with other comments that JDE cannot be expected to encrypt the database traffic. If you can imagine, this would require that instead of using the native database driver they transported all data requests over their JDENet protocol to and from the enterprise server where they would then be passed to the database server and responses passed back through JDENet. This is similar to the way that the little used JDBNET protocol facilitates data access between an AS/400 and a SQL Server or Oracle Server.

Each database has its own way of doing encrypted connectivity. In your case you would need to enable SSL on the AS/400 and then change your underlying ODBC connections on each client PC to use SSL.

I have not tried this with OneWorld. Before anybody whines that it is not supported, a quick search of the Knowledge Garden makes no mention of it. So in my opinion it is not "NOT" supported. I say if you want to invest the time to configure SSL on your AS/400 with certificates and all else that is required then give it a try on a OneWorld client. If it works then let us know. Others might want to give it a try. Remember that since the choice of SSL is at the connection level you can test this on one client without impacting others. If it does not work I would put in a call with response line. If they give you the lame 1st level support answer that it is not supported then contact your client manager and escalate it. Probably they won't fix it given the upcoming changes in ERP 9 but it is good for everybody to voice our opinions to JDE and keep 'em in line.