Various security services have been developed to secure networked applications. These services include multiple versions of Kerberos, NTLM, and SESAME (an extension of Kerberos). Because it is difficult to rework an application to remove its dependence on some security service and place its dependence on another security service, the Generic Security Services Application Program Interface (GSS-API) was developed to provide a standard API for simplifying access to these services. A security service vendor typically provides an implementation of GSS-API as a set of libraries that are installed with the vendor’s security software. Underlying a GSS-API implementation sits the actual Kerberos, NTLM, or other mechanism for providing credentials.
■ Note Microsoft provides its own proprietary GSS-API variant, known as Security Service Provider Interface (SSPI), which is highly Windows-specific and somewhat interoperable with the GSS-API.
A pair of networked peers may have multiple installed GSS-API implementations from which to choose. As a result, the Simple and Protected GSS-API Negotiation (SPNEGO) pseudo-mechanism is used by these peers to identify shared GSS-API mecha- nisms, make an appropriate selection, and establish a security context based on this choice.
Microsoft’s negotiate authentication scheme (introduced with Windows 2000) uses SPNEGO to select a GSS-API mechanism for HTTP authentication. This scheme currently supports only Kerberos and NTLM. Under Integrated Windows authentication (which was formerly known as NTLM authentication, and also known as Windows NT Challenge/
Response authentication), if Internet Explorer tries to access a protected resource from IIS, IIS sends two WWW-Authenticate headers to this browser. The first header has Negotiate as the token; the second header has NTLMas the token. Because Negotiateis listed first, it has first crack at being recognized by Internet Explorer. If recognized, the browser returns both NTLM and Kerberos information to IIS. IIS uses Kerberos when the following are true:
• The client is Internet Explorer 5.0 or later.
• The server is IIS 5.0 or later.
• The operating system is Windows 2000 or later.
• Both the client and server are members of the same domain or trusted domains.
Otherwise, NTLM is used. If Internet Explorer does not recognize Negotiate, it returns NTLM information via the NTLM authentication scheme to IIS.
According to the JDK documentation’s “Http Authentication” section, a client can provide an Authenticatorsubclass whose getPasswordAuthentication()method checks the scheme name returned from the protected final String getRequestingScheme()method to see if the current scheme is "negotiate". If this is the case, the method can then pass the username and password to the HTTP SPNEGO module (assuming that they are needed—no credential cache is available), as illustrated in the following code fragment:
class MyAuthenticator extends Authenticator {
public PasswordAuthentication getPasswordAuthentication () {
if (getRequestingScheme().equalsIgnoreCase("negotiate")) {
String krb5user; // Assume Kerberos 5.
char[] krb5pass;
// get krb5user and krb5pass in your own way ...
return (new PasswordAuthentication (krb5user, krb5pass));
} else {
...
} } }
Summary
Java SE 6 introduces several new networking features, beginning with the CookieManager class. This class provides a concrete implementation of the CookieHandlerclass, and works with a cookie store and cookie policy so that HTTP protocol handlers and applica- tions can handle cookies.
Because many of the world’s users would like to register and access domain names using language-specific characters, the Internet Engineering Task Force’s Network Work- ing Group introduced support for internationalized domain names. This support consists of ToASCII and ToUnicode operations that specify how to translate between ASCII and non-ASCII domain names. Java SE 6 supports these operations via an IDNclass and its methods.
Sun has included a lightweight HTTP server in Java SE 6, which is especially useful in testing web services. The server implementation supports the HTTP and HTTPS proto- cols. Its com.sun.net.httpserverpackage contains 17 classes, with HttpServer, HttpsServer, HttpContext, and HttpExchangebeing the 4 most important classes.
Java SE 6 adds new methods to the NetworkInterfaceclass that let you access a physical network interface’s hierarchy of multiple virtual subinterfaces, as well as other parameters such as the maximum transmission unit. NetworkInterface’s
getInterfaceAddresses()method returns a list of InterfaceAddressobjects that contain a network interface’s IP addresses, broadcast addresses (IPv4), and subnet masks (IPv4) or network prefix lengths (IPv6).
Finally, Java SE 6 supports Microsoft’s negotiate HTTP authentication scheme. To understand this scheme, you first need to understand HTTP authentication basics. The basics begin with the challenge-response mechanism, credentials, and authentication schemes; continue with the basic, digest, NTLM, and Kerberos schemes; and conclude with GSS-API, SPNEGO, and the negotiate scheme.
Test Your Understanding
How well do you understand Java SE 6’s new networking features? Test your understand- ing by answering the following questions and performing the following exercises.
(The answers are presented in Appendix D.)
1. In Listing 8-1, what would happen if you placed new URL (args [0]).
openConnection ().getContent ();before CookieManager cm = new CookieManager ();? Why would it happen?
2. Which pair of IDNmethods—toASCII()or toUnicode()—throws
IllegalArgumentExceptionif the input string does not conform to RFC 3490?
3. Extend MinimalHTTPServer(Listing 8-4) with a second handler that is associated with the /dateroot URI. Whenever the user specifies http://localhost:8000/date, the server should return an HTML page that presents the current date bolded and centered. Assume the default locale.
4. Extend the network parameters application (Listing 8-5) to obtain all accessible InterfaceAddresses for each network interface. Output each InterfaceAddress’s IP address, broadcast address, and network prefix length/subnet mask.