You are here: SCDJWS » JAX-RPC


SCDJWS Study Guide: JAX-RPC


Printer-friendly version Printer-friendly version | Send this article to a friend Mail this to a friend

Previous Next vertical dots separating previous/next from contents/index/pdf Contents

Security Mechanisms in JAX-RPC


HTTP Basic Authentication


JAX-RPC implementation has to support HTTP Basic Authentication. JAX-RPC specification does not require JAX-RPC implementation to support certificate based Mutual Authentication using HTTP/S (HTTP over SSL).

The HTTP 1.x protocol has a built in mechanism for requiring a valid username/password to gain access to web resources. This mechanism is known as HTTP Authentication and can be initiated by either a CGI script or by the web server itself. With HTTP basic authentication, the web server authenticates a user by using the user name and password obtained from the web client.
HTTP Basic Authentication
(Figure come from SUN Microsystem Inc.)

With basic authentication, the following things occur:

  1. A client requests access to a protected resource.
  2. The web server returns a dialog box that requests the user name and password.
  3. The client submits the user name and password to the server.
  4. The server validates the credentials and, if successful, returns the requested resource.

HTTP basic authentication is not particularly secure. Basic authentication sends user names and passwords over the Internet as text that is uu-encoded (Unix-to-Unix encoded) but not encrypted. This form of authentication, which uses Base64 encoding, can expose your user names and passwords unless all connections are over SSL. If someone can intercept the transmission, the user name and password information can easily be decoded.

Example: Basic Authentication with Browser

The following shows steps of the Basic Authentication exchange between Client (Web browser) and Server:


  1. Client sends standard HTTP request for resource

    GET /download/report.doc HTTP/1.1
    Accept: application/msword, */*
    Accept-Language: en-us
    Accept-Encoding: gzip, deflate
    User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
    Host: 10.0.0.5:81
    Connection: Keep-Alive

  2. Server reads configuration files and determines that resource falls within a protected directory.

    Server can only allow access to known users.
  3. Server Sends HTTP 401 Authorization Required Response

    HTTP/1.1 401 Authorization Required
    Date: Sat, 20 Oct 2001 19:28:06 GMT
    Server: Apache/1.3.19 (Unix)
    WWW-Authenticate: Basic realm="File Download Authorization"
    Keep-Alive: timeout=15, max=100
    Connection: Keep-Alive
    Transfer-Encoding: chunked
    Content-Type: text/html; charset=iso-8859-1

    Note: html error page for browser to show if user hits cancel.
  4. Browser displays Username/ Password prompt displaying host name and authentication realm.
  5. Client Resubmits Request with Username/ Password

    GET /download/report.doc HTTP/1.1
    Accept: application/msword, */*
    Accept-Language: en-us
    Accept-Encoding: gzip, deflate
    User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
    Host: 10.0.0.5:81
    Connection: Keep-Alive
    Authorization: Basic ZnJlZDp0aGF0cyBtZQ==

  6. Server compares client information to its user/password list.
    • username : password is valid: server sends requested content.
    • authorization fails:  server resends 401 Authorization Required header
    • Client hits cancel:  browser shows error message sent along with 401 message.

From the above dialogue you will notice several special fields have been added to the various Http headers. In step 3 when the server sends the 401 response it includes a special field:

WWW-Authenticate: Basic realm="File Download Authorization"

The value "Basic" denotes that we are requesting the browser to use Basic Authentication. The Realm information is an arbitrary string sent to be displayed to the user commonly containing a sight message, or feedback. The image in Step 4 shows Internet Explorer's HTTP Authorization Dialogue and how it displays the sight and realm data received.
The user fills in the form and clicks ok. The browser automatically resends the request as seen in step 5. Here you will notice a new field has been added to the standard http request:

Authorization: Basic ZnJlZDp0aGF0cyBtZQ==

This is where the web browser sends the actual authorization information to the server. The Authorization field shown is composed of two values. The word Basic denotes that the login is being send in accordance with the Basic Authentication method. The block of data that follows that is the actual login as supplied by the browser. Don't let the logins appearance fool you. This is not an encryption routine, but a base 64 transfer encoding.

The plain-text Login can be trivially decoded to its underlying username:password format

ZnJlZDp0aGF0cyBtZQ==   -> base64Decode() -> "fred:thats me"

Example: Basic Authentication with JAX-RPC

  1. Add the appropriate security elements to the web.xml deployment descriptor:

    <?xml version="1.0"?>
    <web-app version="2.4" ...>
      <display-name>Basic Authentication Security Example</display-name>
      <security-constraint>
        <web-resource-collection>
          <web-resource-name>SecureHello</web-resource-name>
          <url-pattern>/hello</url-pattern>
          <http-method>GET</http-method>
          <http-method>POST</http-method>
        </web-resource-collection>
     
        <auth-constraint>
          <role-name>admin</role-name>
        </auth-constraint>
     
        <user-data-constraint>
          <transport-guarantee>NONE</transport-guarantee>
        </user-data-constraint>
      </security-constraint>
               
      <login-config>
        <auth-method>BASIC</auth-method>
      </login-config>

      <security-role>
        <role-name>admin</role-name>
      </security-role>
    </web-app>                                                    

  2. Set security properties in the client code:  For basic authentication, the client code must set username and password properties. The username and password properties correspond to the admin group (which includes the user name and password combination entered during installation) and the role of admin, which is provided in the application deployment descriptor as an authorized role for secure transactions.

    import javax.xml.rpc.Stub;
     
    public class HelloClient {
     
      public static void main(String[] args) {
       
        if (args.length !=3) {
          System.out.println("HelloClient Error: Wrong
               number of runtime arguments!");
          System.exit(1);
        }
           
        String username=args[0];
        String password=args[1];
        String endpointAddress=args[2];
     
        // print to display for verification purposes
        System.out.println("username: " +
                     username);
        System.out.println("password: " + password);
        System.out.println("Endpoint address = " +
               endpointAddress);
     
     
        try {
          Stub stub = createProxy();
          stub._setProperty(
              javax.xml.rpc.Stub.USERNAME_PROPERTY,
              username);
          stub._setProperty(
              javax.xml.rpc.Stub.PASSWORD_PROPERTY,
              password);
          stub._setProperty(
              javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY,
              endpointAddress);
     
          HelloIF hello = (HelloIF)stub;
          System.out.println(hello.sayHello("Duke (secure)"));
        } catch (Exception ex) {
          ex.printStackTrace();
        }
      }   
     
      private static Stub createProxy() {
        // Note: MyHelloService_Impl is implementation-specific.
        return (Stub)(new MyHelloService_Impl().getHelloIFPort());
      }
    }

Basic Authentication transmits the username:password pair in an unencrypted form from browser to server and in such should not be used for sensitive logins unless operating over an encrypted medium such as SSL.

Client-Certificate Authentication

Client-certificate authentication is a more secure method of authentication than either basic or form-based authentication. It uses HTTP over SSL, in which the server and, optionally, the client authenticate one another using public key certificates.

Secure Socket Layer (SSL) provides data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection. You can think of a public key certificate as the digital equivalent of a passport. It is issued by a trusted organization, which is called a certificate authority (CA), and provides identification for the bearer.

If you specify client-certificate authentication, the web server will authenticate the client using the client's X.509 certificate, a public key certificate that conforms to a standard that is defined by X.509 Public Key Infrastructure (PKI). Before running an application that uses SSL, you must configure SSL support on the server (see Installing and Configuring SSL Support) and set up the public key certificate (see Understanding Digital Certificates).

Using Mutual Authentication

With mutual authentication, the server and the client authenticate each other. There are two types of mutual authentication.

Certificate-based mutual authentication

Certificate-based Mutual Authentication
Certificate-Basic Mutual Authentication
(Figure come from SUN Microsystem Inc.)

In certificate-based mutual authentication, the following things occur:

  1. A client requests access to a protected resource.
  2. The web server presents its certificate to the client.
  3. The client verifies the server's certificate.
  4. If successful, the client sends its certificate to the server.
  5. The server verifies the client's credentials.
  6. If successful, the server grants access to the protected resource requested by the client.

Example: Client-Certificate Authentication for the Mutual Authentication

Step 1. Configure SSL connector

Step 2. Add the appropriate security elements to the web.xml deployment descriptor:

<?xml version="1.0"?>
<web-app version="2.4" ...>
  <display-name>Secure Mutual Authentication Example</display-name>
 
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>SecureHello</web-resource-name>
      <url-pattern>/hello</url-pattern>
      <http-method>GET</http-method>
      <http-method>POST</http-method>
    </web-resource-collection>
 
    <user-data-constraint>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
  </security-constraint>

  <login-config>
    <auth-method>CLIENT-CERT</auth-method>
  </login-config>
</web-app>

Step 3. Set Security Properties in client code:

package mutualauthclient;
import javax.xml.rpc.Stub;
public class HelloClient {
 
  public static void main(String[] args) {
   
    if (args.length !=5) {
      System.out.println("HelloClient Error: Need 5 runtime arguments!");
      System.exit(1);
    }
       
    String keyStore=args[0];
    String keyStorePassword=args[1];
    String trustStore=args[2];
    String trustStorePassword=args[3];
    String endpointAddress=args[4];
 
 
    // print to display for verification purposes
    System.out.println("keystore: " + keyStore);
    System.out.println("keystorePassword: " +
                        keyStorePassword);
    System.out.println("trustStore: " + trustStore);
    System.out.println("trustStorePassword: " +
                       trustStorePassword);
    System.out.println("Endpoint address: " +
                        endpointAddress);
 
    try {
      Stub stub = createProxy();
      System.setProperty("javax.net.ssl.keyStore", keyStore);
      System.setProperty("javax.net.ssl.keyStorePassword",
                         keyStorePassword);
      System.setProperty("javax.net.ssl.trustStore",
                         trustStore);
      System.setProperty("javax.net.ssl.trustStorePassword",
                         trustStorePassword);
      stub._setProperty(
          javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY,
          endpointAddress);
 
      HelloIF hello = (HelloIF)stub;
     
      System.out.println(hello.sayHello("Duke!(secure!"));
    } catch (Exception ex) {
      ex.printStackTrace();
    }
  }   
 
  private static Stub createProxy() {
    //Note: MyHelloService_Impl is implementation-specific.
    return (Stub)
           (new MySecureHelloService_Impl().getHelloIFPort());
  }
}

 

User name- and password-based mutual authentication

UserName/Password-based Mutual Authentication
UserName/Password-Basic Mutual Authentication
(Figure come from SUN Microsystem Inc.)


In user name- and password-based mutual authentication, the following things occur:

  1. A client requests access to a protected resource.
  2. The web server presents its certificate to the client.
  3. The client verifies the server's certificate.
  4. If successful, the client sends its user name and password to the server, which verifies the client's credentials.
  5. If the verification is successful, the server grants access to the protected resource requested by the client.

References


http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security5.html

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security6.html

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security7.html

Previous Next vertical dots separating previous/next from contents/index/pdf Contents

  |   |   
© Copyright 2005-2012 www.xyzws.com All rights reserved.