![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Security
Security has become a prime concern these days due to the financial damages caused by malicious hack attacks. As an architect, you should be in a position to minimize these attacks by building a robust security model for your application. In this section, we briefly introduce to the Java 2 security model and the security restrictions on applets. Later, we discuss important security concepts, such as authentication, authorization, symmetric and asymmetric encryption algorithms, and digital signatures and certificates. We end this section with a discussion on topologies.
In JDK 1.1, any downloaded code, such as applets, was considered untrusted and consequently run in a restricted sandbox, whereas local applications and signed applets were given full access to the system resources. The Java 2 security model changes this coarse-grained approach to a fine-grained, policy-driven approach. When code is loaded, a policy file is read, and the allowed permissions are granted to the code. The permissions can be anything from read or write access to a directory to connect permission to a host computer. Code can access the resource only if it has been granted the required permissions for accessing that resource. Permission classes are extensible, so custom permissions and properly configured policy files provide the required granularity of security.
Applets are Java programs that run inside the Web browser. They are typically embedded in a Web page to add dynamic behavior. Applets are loaded with a restrictive policy file. The most important restrictions are:
- Making network connections to arbitrary hosts other than the originating host.
- Reading/writing on the client file system.
- Starting other programs on the client.
- Loading native libraries.
- Defining native methods.
- Any operation that could be detrimental to the client system. (This excludes attacks such as excessive usage of CPU, memory, and network resources, as they can be handled at the OS level.)
It is important to know that these restrictions do not apply to applets loaded from the local file system whose classes are present in the client's CLASSPATH.
Following are some of the fundamental terminologies you must be familiar with when dealing with security issues:
-
Principal
Any identifiable person, role, or a system.
-
Authentication
The means by which communicating entities prove to one another that they are acting on behalf of specific identities authorized for access (that is, the process by which a user or a system is identified by the other party). For example, a customer logs in to a bank's Web site using his or her login and password. This combination of user name and password identifies the user to the system.
-
Authorization
The means by which interactions with resources are limited to collections of users or programs for the purpose of enforcing integrity, confidentiality, or availability constraints. For example, a manager can see all the employee details, whereas employees can only see their details.
-
Data integrity
The means used to prove that information has not been modified by a third party while in transit. For example, if you send a file and its checksum separately, the receiving party can compute the file's checksum and match it with the received checksum to ensure the file's contents were not tampered with along the way.
-
Confidentiality (data privacy)
The means used to ensure that information is made available only to the users who are authorized to access it. For example, you can encrypt the data and send. The receiver who has the decrypting key alone would be able to read the data.
Cryptography is the practice and study of encryption and decryption -- encoding data so it can only be decoded by intended recipients and rendered unreadable for others. There are two forms of encryption:
- Symmetric
- Asymmetric
Both sender and recipient know a common key used to encrypt and decrypt messages. Because the keys are same for both encrypting and decrypting, it is known as symmetric encryption.
One benefit of this method is:
- Requires significantly less resources in terms of CPU cycles to encrypt and decrypt the data.
A disadvantage of this method is:
- Both the sender and receiver must share the key in a secure way. If it is leaked to a third party, the entire mechanism becomes futile.
Two different but related keys are used in such a way that one key, called a private key, is kept as a secret, while the other public key is available to anyone. The two fundamental principles that drive this method are:
- One key cannot be deduced from the other.
- Messages encrypted with one key can only be decrypted by the other and vice versa.
One advantage of this method is:
- Completely eliminates the need to securely share the keys, as a sender can use the recipient's public key to encrypt the message, which can be read only by the recipient using his or her secure private key.
One downside of this method is:
- It is computationally expensive.
In reality, you can use both forms of encryption in combination for enhanced security and efficient use. You can use symmetric encryption to encrypt the message, thereby reducing the computational cost involved in decrypting; the shared key (which would be small compared to the data) is encrypted using the asymmetric encryption, eliminating the necessity to transfer the keys securely.
Digital signatures and certificates
You can use asymmetric keys to verify the sender. Let's say if a message can be decrypted using one's public key, it ensures that it was encrypted using the sender's private key. This fact can be used to verify the sender's authenticity because he or she is the only one who has access to his or her private keys (provided it has not been hacked by someone else).
But how do you get an individual's public key, and how do you know that it's really his or her public key? A certificate that contains the name of the individual, expiration date, and a copy of the individual's public key solves this dilemma. A central certificate issuing authority called the Certificate Authority (CA) verifies people's identity and grants them the certificates. The granted certificates are digitally signed by the CA to ensure their credibility. The CA certificates are typically installed, by default, in applications such as Internet browsers. The CA is trustworthy, so the individuals who are trusted by it are also trustworthy. This chain of trust is what makes the entire system function properly.
Certificates are issued in various strengths depending on the level of credibility the CA has on the individual. A certificate of the lowest grade could be obtained by simply proving you have a valid e-mail ID, whereas a commercial grade might require advanced identification techniques such as DNA test.
The CA's job does not end with issuing of certificates. It's also in charge of maintaining the certificate's status. If someone's private key is lost, he or she can report the theft to the CA that issued the certificate. CA adds the certificate to the CA Revocation List (CRL) that lists the compromised certificates. Anyone can access this database to ensure that the certificate they trust is not a malicious one.
Network topologies for implementing security
The layout of the network has a strong correlation with the security of the network. Multiple entry points to the network without proper access control mechanisms are a boon for intruders looking to penetrate corporate networks. For enhanced security, the entry points into the network have to be restricted and must be guarded by well-configured firewalls. Once the topology is set, there must be constant monitoring of the firewall, server, and other network equipment log files to uncover any malicious activities, such as unauthorized intrusions, in a timely manner.
This is a simple model in which the internal network and the external network are separated by a firewall.
You use this model when you must offer a significant amount of services to the external network. You place the externally accessible servers in a demilitarized zone (DMZ) surrounded by firewalls on either side of the network. You configure the inner firewall more restrictively than the other firewall. Any communication from the external network to the internal network happens only through the servers deployed in the DMZ.
The firewall setup does not generally allow every protocol to communicate through it. Opening up numerous ports can result in an extremely vulnerable firewall. So, administrators generally allow only well-defined protocols, such as HTTP and HTTPS.
You can use tunneling to access an external service that is not allowed by the firewall by piggy-backing the requests onto a protocol that is allowed by the firewall (for example, using HTTP as a covert channel for invoking Web services).
Similarly, external networks can tunnel into an internal network. But this is not good practice as it allows anyone with malicious intentions to bypass the firewall rules.
In this section, we discussed the security model of the Java language and the fundamentals of security required to face this exam. Remember the security restrictions imposed for an applet. Also, try to understand the various basic concepts of security, such as cryptography, signatures, firewalls, DMZ, and tunneling. The exam does not require you to know, in detail, the algorithms and mechanisms; rather, it tests your overall knowledge on the concepts and terminologies.
Which of the following statements are true about a DMZ?
Choices:
- A. A DMZ is the zone secured behind a firewall.
- B. A DMZ is the zone before a firewall.
- C. A DMZ is the zone in front of two firewalls.
- D. A DMZ is the zone between 2 firewalls.
Correct choice:
D
Explanation:
Choice D is the correct answer.
A DMZ is the zone between two firewalls. Hence, choice D is correct. The remaining choices are incorrect as they do not describe a DMZ.
Table of contents
Next steps from IBM
Rational Application Developer features provide the comprehensive Integrated Development Environment (IDE) used to develop J2EE applications requiring Servlets and JavaServer Pages (JSPs).
- Try: Try the free Rational Application Developer, which helps developers quickly design, develop, test, analyze, and deploy high-quality Java, Javaserver pages, and J2EE applications.
- Article: Learn how you can deliver accurate, higher-quality J2EE apps with Rational Application Developer, open source JUnit and JUnitEE test frameworks.
- Tutorial: Build a Facebook application using PHP, the Spring framework, and J2EE.
- Demo: This demo shows how to use the new Java EE 5 Java Persistence API (JPA) framework.
- Buy: Rational Application Developer
