NAV Web Security

boone

My company is currently in the process of upgrading to NAV 2013, but we will likely turn right around and begin the upgrade process, or at least testing, of NAV 2015 shortly after. One of the main things I'm looking at in the features of 2015 is the Office365 integration, web services with SharePoint, and tablet integration. I have a lot of ideas for ways to use these integrations to deliver data to our employees in the field, but my IT Director has concerns over security. Basically, he doesn't want to expose our internal system to the outside internet. He focuses mainly on the hardware/server/infrastructure of our IT, whereas I'm focused on the NAV/end-user/data side. So unfortunately, our knowledge bases don't crossover too well, so I'm not sure exactly how to ease his security concerns, or if he has legitimate concerns, how to understand them better myself. Can anybody give me some further information, or point me in the direction of some, on the security protocols in NAV.

Thank you!

vremeni4

Hi,

The data exchanged in NAV between user e.g. Windows client and NAV server is encrypted with Certificates (based on private and public key).
See here for more http://msdn.microsoft.com/en-us/library/gg502476.aspx

Regarding Office 365 everything is also encrypted.
For more information see
http://office.microsoft.com/en-gb/business/office-365-trust-center-cloud-computing-security-FX103030390.aspx
I think there is no ISO standard that Microsoft does not have to prove the security of Office 365.

To elaborate this in more detail:
An SSL certificate is used to authenticate the company and servers e.g. NST and Transport Layer Security (TLS) is used to secure RoleTailored client connections over a wide area network (WAN).
The SSL certificate is installed on the NST.
In fact this is the same type of encryption used to protect e.g. credit card payments. All data exchanged between NAV 2013 R2 RoleTailored Client and NAV 2013 R2 NST is encrypted in this way.
The encryption method used is so called Public-key cryptography, also known as asymmetric cryptography. This cryptographic algorithm requires two separate keys, one of which is secret (or private) and one of which is public. Although different, the two parts of this key pair are mathematically linked. The public key is used to encrypt messages whereas the private key is used to decrypt cipher text.
The public key is made public and available to everyone. If a person e.g. Bob wants to send an encrypted message to e.g. Alice, then Bob will use Alice’s public key to encrypt the message. As Alice is the only person that has the private key she is the only one who can encrypt the message.

A public key certificate, usually just called a certificate, is a digitally-signed statement that binds the value of a public key to the identity of the company, device, or service that holds the corresponding private key. One of the main benefits of certificates is that hosts no longer have to maintain a set of passwords for individual subjects who need to be authenticated as a prerequisite to access. Instead, the host merely establishes trust in a certificate issuer.
Typically, certificates contain the following information:

• The subject's public key value.
• The subject's identifier information, such as the name and email address.
• The validity period (the length of time that the certificate is considered valid).
• Identifier information about the issuer.
• The digital signature of the issuer, which attests to the validity of the binding between the subject’s public key and the subject’s identifier information.

The public key plus the distinguishing information about the company is sent to the CA which then creates a digitally signed document, signed using the CA’s private key. The certificate is returned by the CA, and installed on the NST server. The private key is only known to CA.

When users connect to the NAV 2013 R2 Server NST via RoleTailored Client, the RoleTailored Client retrieves the certificate and a signature validation is performed on it. The certificate was signed by the CA’s private key, so the CA can perform the validation. If something is wrong with the certificate the RoleTailored client will reject the connection. When connection is established the system uses Windows Communication Foundation (WCF) transport-level security (TLS) over the TCP/IP protocol to encrypt the messages.
In other words the SSL certificate is used to exchange a session key for TLS. This session key is then used to encrypt data flowing between the parties. This allows for data/message confidentiality and message authentication codes for message integrity and as a by-product, message authentication. An important property in this context is forward secrecy, so the short-term session key cannot be derived from the long-term asymmetric secret key.

In the configuration file “ClientUserSettings.config” for the RoleTailored client there is option to set a specific DNS Identity. If DNS Identity is incorrect the client will reject the connection.
The DNS Identity value is used to authenticate the service. After the client initiates a communication to an endpoint and the service authenticates itself to the client, the client compares the endpoint identity value with the actual value the endpoint authentication process returned. If they match, the client is assured it has contacted the expected service endpoint. This functions as a protection against phishing by preventing a client from being redirected to an endpoint hosted by a malicious service.

I hope this helps.

Thanks

boone

Thank you for the info! A lot of that was over my head, but I think it was exactly what I needed. Thank you for taking the time to help me!