Security

Most browsers such as Netscape Navigator, Internet Explorer and HotJava today support https, i.e. secure http via SSL (Secure Socket Layer), at the language level. This makes it very straightforward to write distributed applications for secure transactions in Java, e.g. advanced client-server applications  -  making it possible to extend many otherwise intranet-restricted applications to the internet, i.e. transmitting sensitive data etc. The flourishing electronic commerce today signifies the possibilities that are open to explore.

Cryptography

It is also possible to implement any custom scheme for encryption and authentication with the JCE (Java Cryptography Extension) which is in beta at the time being.  With the upcoming JCE 1.2 standard, it will be easy to write generic, "strong" encryption applications, e.g. for "wide area intranet solutions" over the internet.

Due to US export restrictions, "strong" cryptographic software cannot be exported to Europe (or to any place outside US or Canada). However, this is no general problem as there exists independent implementations of JCE developed outside US (based on the JCE spec.), that thus are not subject to any restrictions.  A clean room implementation of JCE1.1 is available today from the Cryptrix project, and JCE1.2 is under way.

Language security

Java's inherent language security and platform independence has made distributed applications possible like never before. But why is Java safe?

Firstly, the language does not use explicit memory pointers, which are the most common loopholes used for computer viruses in C/C++; it is a strongly typed language, that enforces type checking at runtime via the bytecode verifier, before the code is actually executed. The verifier ensures that the code is legal and that there are no illegal type conversions that would allow the program to access other segments of the memory.
 
Secondly, the Java runtime (the virtual machine) has  a security manager, that checks any requests for network or file resources at runtime. Since it is possible to configure and subclass the security manager, it is possible to implement your own security strategies for your application.

Code authentication

Code that need access to restricted resources can distributed in a JAR (Java ARchive) file. A JAR file can be digitally signed to ensure that the code has not been modified or tampered with, and that it really comes from the correct site. Upon execution of the code the  browser environment asks the user whether or not to grant the downloaded code permission to e.g. write to restricted areas on the file system, access the printer, or to be able to connect to other hosts on the internet. The user, or the security settings by the company's system manager, can then grant or deny any request, depending on the possible security risk, and the trust for the site that the code has been loaded from (e.g. different policies can be used depending on whether the code comes from the local intranet, from a well known company's site, or from a more unknown place.)

The JAR file format is part of the java standard (although Microsoft have their own CAB format for signed code instead). The for the code to request permissions will be more standardized in upcoming releases of Java, for the time being there are different ways to do it depending on whether you run the Netscape browser, which relies on its capabilities classes, Internet Explorer, which uses security zones.

For an Applet it can also be of interest to interact with a script in the browser (e.g. JavaScript) which can also be signed.

Other Java Security Links

There are of course a lot of documents on the net about Java and security, you'll find  documentation and  security overviews at Javasoft - or why not have a look at the Java Security Hotlist.