With the increasing use of distributed systems, users often need to access multiple resources to finish a single business transaction. Traditionally, users have had to sign on to all these systems, each of which may involve different usernames and authentication requirements. With the introduction of the single sign-on technique, users can login once and be authenticated for all systems involved in a given business transaction.

Although the single sign-on concept is appealing, implementing it is not at all easy because enterprise systems often have varying security requirements and a wide range of underlying technologies on which they are deployed. In Java environments, Java Authentication and Authorization Service (JAAS) has made implementation easier. JAAS, a significant enhancement to the Java security architecture, is an ideal tool for access control in a multi-user environment where users must be granted varying privileges. Unlike the standard JDK security model, which is code-source-based permission checking, JAAS controls access to resources with both code-source-based and user/role-based permission checking. Most importantly, the "pluggable" and stackable login module architecture that JAAS defines makes it instrumental in supporting legacy security implementations on different technologies and serves as a useful mechanism for implementing single sign-on.

Single sign-on can be implemented for applications that are deployed either locally or over a network. In the case of a network, after the user logs into the primary domain, an encrypted secure token is created and sent over the wire to other applications. In local networks, user credential data is exchanged directly between applications. Both deployment options share two key challenges: passing user credential information between involved domains and translating this information.

An enterprise application can be comprised of several Web applications, each of which may depend on different technologies and data stores to retrieve the user information it needs to authenticate the user and determine his or her privilege. If a business transaction crosses the Web application boundary, the user needs to log into each Web application and present similar credentials to each of the application authentication services.

This article demonstrates a single sign-on implementation for multiple Web applications based on JAAS. Specifically, it introduces an approach to achieving single sign-on between Web applications deployed on the same application server.

LogisticsEnterpriseApplication
{
   com.cysive.framework.security.ldap.LDAPLoginModule 
   required name=CarrierSecurityDomain;
   com.cysive.framework.security.ldap.LDAPLoginModule 
   required name=ShipperSecurityDomain  useSharedState=true;
};

com.cysive.framework.security.ldap.LDAPLoginModule 
required DriverName="oracle.jdbc.driver.OracleDriver" 
InitialCapacity="0" MaxCapacity="10" Properties="user=cymbio;password=cymbio 
URL="jdbc:oracle:thin:@jtao1:1521:jtao1"; 	

As I wrote in a DevX 10-Minute Solution, "JAAS Security in Action": JAAS “is a flexible, standardized API that supports runtime pluggability of security modules.” If you are unfamiliar with JAAS, I recommend reading that article and reviewing the downloadable code before continuing, as this article assumes an understanding of JAAS. It takes the next logical step from a security architecture standpoint: integrating your J2EE security model to provide SSO across multiple subsystems by leveraging your existing LDAP directory server, database server, or any other enterprise security system.

Before going any further, let's clarify how this article uses the term "domain": It refers to security domains (LDAP, database, etc.) and not Web domains. If you are interested in using JAAS to share authentication information between multiple Web applications, read the article "Implement Single Sign-on with JAAS" written by James Tao in October of 2002. Additionally, if you are interested in Web applications that exist across firewalls and participate in some sort of Web service exchange, read the joint Web Single Sign-On Identify specifications that Microsoft and Sun recently published.

Securing the Enterprise

Regardless of whether the deployment scenario is local, across a network, or a combination of the two, the security challenges are the same: sharing credentials between domains, correctly interpreting the credentials once received, and managing different sets of privileges across these domains (e.g., a user could be a manager within one system, a power user in another system, and a normal user in a third).

Finally, the heterogeneous nature of most enterprise systems creates some unique challenges for SSO security architectures. Each application within the enterprise could be comprised of different technologies, operate on different platforms, access disparate data sources, and except slightly different authentication credentials for the same principal (user). In spite of these overwhelming obstacles, JAAS combined with LDAP provides a solid framework for designing and implementing a robust SSO enterprise security framework.

BasicAuth {
	com.xyz.ldap.LDAPLoginModule 
required name=LDAPSecurityDomain;
};

DBAccessAuth {
	com.xyz.ldap.LDAPLoginModule 
required name=LDAPSecurityDomain;
com.xyz.db.OracleLoginModule
required name=OracleSecurityDomain
useSharedState=true;
};

LoginContext ctx = new LoginContext( "DBAccessAuth", new SimpleCallbackHandler() );

• Installation and Setup
• Non MSIE Clients and "Basic" Authentication
• JCIFS Properties Meaningful to NTLM HTTP Authentication
• Must Restart The Container
• Tomcat
• MalformedURLException: unknown protocol: smb
• Transparent Authentication and the Network Password Dialog
• Personal Workstation AD Security Policy
• HTTP POST and Protecting Sub-Content
• SMB Signatures and Windows 2003
• NTLM HTTP Authentication Protocol Details

Installation and Setup

Production web.xml Example

<filter>
    <filter-name>NtlmHttpFilter</filter-name>
    <filter-class>jcifs.http.NtlmHttpFilter</filter-class>

    <init-param>
        <param-name>jcifs.smb.client.domain</param-name>
        <param-value>NYC-USERS</param-value>
    </init-param>
    <init-param>
        <param-name>jcifs.netbios.wins</param-name>
        <param-value>10.169.10.77,10.169.10.66</param-value>
    </init-param>
</filter>

<filter-mapping>
    <filter-name>NtlmHttpFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Alternate web.xml Example

<filter>
    <filter-name>NtlmHttpFilter</filter-name>
    <filter-class>jcifs.http.NtlmHttpFilter</filter-class>

    <init-param>
        <param-name>jcifs.http.domainController</param-name>
        <param-value>192.168.2.15</param-value>
    </init-param>
    <init-param>
        <param-name>jcifs.smb.client.logonShare</param-name>
        <param-value>JCIFSACL</param-value>
    </init-param>
</filter>

<filter-mapping>
    <filter-name>NtlmHttpFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

NTLM HTTP Authentication Example

NYC-USERS\MIALLEN successfully logged in

Please submit some form data using POST

field1 = hello

null successfully logged in

Non MSIE Clients and "Basic" Authentication

JCIFS Properties Meaningful to NTLM HTTP Authentication

Must Restart The Container

Tomcat

MalformedURLException: unknown protocol: smb

Exception MalformedURLException: unknown protocol: smb
      at java.net.URL.(URL.java:480)
      at java.net.URL.(URL.java:376)
      at java.net.URL.(URL.java:330)
      at jcifs.smb.SmbFile.(SmbFile.java:355)
      ...

Transparent Authentication and the Network Password Dialog

1. The client must be logged into the Windows NT domain identified by the jcifs.smb.client.domain parameter (or the domain of the host identified by the jcifs.smb.client.domainController parameter if it is used instead). The client may also be logged into a domain that has a trust relationship with the target domain. Indeed it is not uncommon to configure workstations to join a different domain from those of users. Note that Windows 95/98/ME systems cannot really join a domain but can be configured to do so enough to participate in transparent NTLM HTTP authentication.
2. Only Internet Explorer will negotiate NTLM HTTP authentication transparently. Mozilla will always prompt the user for credentials (someone please notify us when/if this is not true anymore). At the time this FAQ was written it was not known which other browsers, if any, can negotiate NTLM HTTP authenication transparently.
3. Either the target URL must contain a server in the local domain (e.g. ws1.mycompany.com) or the client's security settings must be changed (e.g. Tools > Internet Options > Security > Local Intranet > Sites > Advanced > add your site). If the URL does not contain a URL in the defined IntrAnet zone (e.g. not an IP address), Internet Explorer will assume that the server is in the IntErnet zone and present the user with the Network Password dialog. It would be very bad if a server on the Internet could convince IE to send it your NTLM password hashes. These hashes are easily cracked with brute force dictionary attacks. To prevent this scenario, IE tries to distinguish between Intranet sites and Internet sites. Here are some important notes to consider when deploying a site with NTLM HTTP Authentication regardless of whether or not jCIFS is used to do it.
   • Internet Explorer May Prompt You for a Password
     http://support.microsoft.com/default.aspx?scid=kb;en-us;Q258063
   • How to Use Security Zones in Internet Explorer
     http://support.microsoft.com/default.aspx?scid=kb;en-us;Q174360
   • An Intranet Site Is Identified as an Internet Site When You Use an FQDN or IP Address
     http://support.microsoft.com/default.aspx?scid=kb;en-us;Q303650
4. The user's credentials must be valid. For example if the account has expired, been disabled or is locked out the Network Password dialog will appear. To determine which error was at fault it will be necessary to modify the NtlmHttpFilter to inspect the SmbAuthException in doFilter.
5. The jCIFS client must support the lmCompatibility level necessary for communication with the domain controller. If the server does not permit NTLMv1 try to set jcifs.smb.lmCompatibility = 3.

Personal Workstation AD Security Policy

<init-parameter>
    <parameter-name>jcifs.netbios.hostname</parameter-name>
    <parameter-value>MYHOSTNAME</parameter-value>
</init-parameter>

HTTP POST and Protecting Sub-Content

SMB Signatures and Windows 2003

NTLM HTTP Authentication Protocol Details

http://davenport.sourceforge.net/ntlm.html
http://www.innovation.ch/java/ntlm.html

This is an attempt at documenting the undocumented NTLM authentication scheme used by M$'s browsers, proxies, and servers (MSIE and IIS); this scheme is also sometimes referred to as the NT challenge/response (NTCR) scheme. Most of the info here is derived from three sources (see also the Resources section at the end of this document): Paul Ashton's work on the NTLM security holes, the encryption documentation from Samba, and network snooping. Since most of this info is reverse-engineered it is bound to contain errors; however, at least one client and one server have been implemented according to this data and work successfully in conjunction with M$'s browsers, proxies and servers.

Note that this scheme is not as secure as Digest and some other schemes; it is slightly better than the Basic authentication scheme, however.

Also note that this scheme is not an http authentication scheme - it's a connection authentication scheme which happens to (mis-)use http status codes and headers (and even those incorrectly).

NTLM Handshake

When a client needs to authenticate itself to a proxy or server using the NTLM scheme then the following 4-way handshake takes place (only parts of the request and status line and the relevant headers are shown here; "C" is the client, "S" the server):

    1: C  --> S   GET ...
    
    2: C <--  S   401 Unauthorized
                  WWW-Authenticate: NTLM
    
    3: C  --> S   GET ...
                  Authorization: NTLM <base64-encoded type-1-message>
    
    4: C <--  S   401 Unauthorized
                  WWW-Authenticate: NTLM <base64-encoded type-2-message>
    
    5: C  --> S   GET ...
                  Authorization: NTLM <base64-encoded type-3-message>
    
    6: C <--  S   200 Ok

Messages

The field flags is presumed to contain flags, but their significance is unknown; the values given are just those found in the packet traces.

Type-1 Message

This message contains the host name and the NT domain name of the client.

    struct {
        byte    protocol[8];     // 'N', 'T', 'L', 'M', 'S', 'S', 'P', '\0'
        byte    type;            // 0x01
        byte    zero[3];
        short   flags;           // 0xb203
        byte    zero[2];

        short   dom_len;         // domain string length
        short   dom_len;         // domain string length
        short   dom_off;         // domain string offset
        byte    zero[2];

        short   host_len;        // host string length
        short   host_len;        // host string length
        short   host_off;        // host string offset (always 0x20)
        byte    zero[2];

        byte    host[*];         // host string (ASCII)
        byte    dom[*];          // domain string (ASCII)
    } type-1-message

                 0       1       2       3
             +-------+-------+-------+-------+
         0:  |  'N'  |  'T'  |  'L'  |  'M'  |
             +-------+-------+-------+-------+
         4:  |  'S'  |  'S'  |  'P'  |   0   |
             +-------+-------+-------+-------+
         8:  |   1   |   0   |   0   |   0   |
             +-------+-------+-------+-------+
        12:  | 0x03  | 0xb2  |   0   |   0   |
             +-------+-------+-------+-------+
        16:  | domain length | domain length |
             +-------+-------+-------+-------+
        20:  | domain offset |   0   |   0   |
             +-------+-------+-------+-------+
        24:  |  host length  |  host length  |
             +-------+-------+-------+-------+
        28:  |  host offset  |   0   |   0   |
             +-------+-------+-------+-------+
        32:  |  host string                  |
             +                               +
             .                               .
             .                               .
             +             +-----------------+
             |             | domain string   |
             +-------------+                 +
             .                               .
             .                               .
             +-------+-------+-------+-------+

Type-2 Message

This message contains the server's NTLM challenge.

    struct {
        byte    protocol[8];     // 'N', 'T', 'L', 'M', 'S', 'S', 'P', '\0'
        byte    type;            // 0x02
        byte    zero[7];
        short   msg_len;         // 0x28
        byte    zero[2];
        short   flags;           // 0x8201
        byte    zero[2];

        byte    nonce[8];        // nonce
        byte    zero[8];
    } type-2-message

                 0       1       2       3
             +-------+-------+-------+-------+
         0:  |  'N'  |  'T'  |  'L'  |  'M'  |
             +-------+-------+-------+-------+
         4:  |  'S'  |  'S'  |  'P'  |   0   |
             +-------+-------+-------+-------+
         8:  |   2   |   0   |   0   |   0   |
             +-------+-------+-------+-------+
        12:  |   0   |   0   |   0   |   0   |
             +-------+-------+-------+-------+
        16:  |  message len  |   0   |   0   |
             +-------+-------+-------+-------+
        20:  | 0x01  | 0x82  |   0   |   0   |
             +-------+-------+-------+-------+
        24:  |                               |
             +          server nonce         |
        28:  |                               |
             +-------+-------+-------+-------+
        32:  |   0   |   0   |   0   |   0   |
             +-------+-------+-------+-------+
        36:  |   0   |   0   |   0   |   0   |
             +-------+-------+-------+-------+

Type-3 Message

This message contains the username, host name, NT domain name, and the two "responses".

    struct {
        byte    protocol[8];     // 'N', 'T', 'L', 'M', 'S', 'S', 'P', '\0'
        byte    type;            // 0x03
        byte    zero[3];

        short   lm_resp_len;     // LanManager response length (always 0x18)
        short   lm_resp_len;     // LanManager response length (always 0x18)
        short   lm_resp_off;     // LanManager response offset
        byte    zero[2];

        short   nt_resp_len;     // NT response length (always 0x18)
        short   nt_resp_len;     // NT response length (always 0x18)
        short   nt_resp_off;     // NT response offset
        byte    zero[2];

        short   dom_len;         // domain string length
        short   dom_len;         // domain string length
        short   dom_off;         // domain string offset (always 0x40)
        byte    zero[2];

        short   user_len;        // username string length
        short   user_len;        // username string length
        short   user_off;        // username string offset
        byte    zero[2];

        short   host_len;        // host string length
        short   host_len;        // host string length
        short   host_off;        // host string offset
        byte    zero[6];

        short   msg_len;         // message length
        byte    zero[2];

        short   flags;           // 0x8201
        byte    zero[2];

        byte    dom[*];          // domain string (unicode UTF-16LE)
        byte    user[*];         // username string (unicode UTF-16LE)
        byte    host[*];         // host string (unicode UTF-16LE)
        byte    lm_resp[*];      // LanManager response
        byte    nt_resp[*];      // NT response
    } type-3-message

                 0       1       2       3
             +-------+-------+-------+-------+
         0:  |  'N'  |  'T'  |  'L'  |  'M'  |
             +-------+-------+-------+-------+
         4:  |  'S'  |  'S'  |  'P'  |   0   |
             +-------+-------+-------+-------+
         8:  |   3   |   0   |   0   |   0   |
             +-------+-------+-------+-------+
        12:  |  LM-resp len  |  LM-Resp len  |
             +-------+-------+-------+-------+
        16:  |  LM-resp off  |   0   |   0   |
             +-------+-------+-------+-------+
        20:  |  NT-resp len  |  NT-Resp len  |
             +-------+-------+-------+-------+
        24:  |  NT-resp off  |   0   |   0   |
             +-------+-------+-------+-------+
        28:  | domain length | domain length |
             +-------+-------+-------+-------+
        32:  | domain offset |   0   |   0   |
             +-------+-------+-------+-------+
        36:  |  user length  |  user length  |
             +-------+-------+-------+-------+
        40:  |  user offset  |   0   |   0   |
             +-------+-------+-------+-------+
        44:  |  host length  |  host length  |
             +-------+-------+-------+-------+
        48:  |  host offset  |   0   |   0   |
             +-------+-------+-------+-------+
        52:  |   0   |   0   |   0   |   0   |
             +-------+-------+-------+-------+
        56:  |  message len  |   0   |   0   |
             +-------+-------+-------+-------+
        60:  | 0x01  | 0x82  |   0   |   0   |
             +-------+-------+-------+-------+
        64:  | domain string                 |
             +                               +
             .                               .
             .                               .
             +           +-------------------+
             |           | user string       |
             +-----------+                   +
             .                               .
             .                               .
             +                 +-------------+
             |                 | host string |
             +-----------------+             +
             .                               .
             .                               .
             +   +---------------------------+
             |   | LanManager-response       |
             +---+                           +
             .                               .
             .                               .
             +            +------------------+
             |            | NT-response      |
             +------------+                  +
             .                               .
             .                               .
             +-------+-------+-------+-------+

The host, domain, and username strings are in Unicode (UTF-16, little-endian) and are not nul-terminated; the host and domain names are in upper case. The lengths of the response strings are 24.

Password Hashes

To calculate the two response strings two password hashes are used: the LanManager password hash and the NT password hash. These are described in detail at the beginning of the Samba ENCRYPTION.html document. However, a few things are not clear (such as what the magic constant for the LanManager hash is), so here is some almost-C code which calculates the two responses. Inputs are passw and nonce, the results are in lm_resp and nt_resp.

    /* setup LanManager password */

    char  lm_pw[14];
    int   len = strlen(passw);
    if (len > 14)  len = 14;

    for (idx=0; idx<len; idx++)
        lm_pw[idx] = toupper(passw[idx]);
    for (; idx<14; idx++)
        lm_pw[idx] = 0;


    /* create LanManager hashed password */

    unsigned char magic[] = { 0x4B, 0x47, 0x53, 0x21, 0x40, 0x23, 0x24, 0x25 };
    unsigned char lm_hpw[21];
    des_key_schedule ks;

    setup_des_key(lm_pw, ks);
    des_ecb_encrypt(magic, lm_hpw, ks);

    setup_des_key(lm_pw+7, ks);
    des_ecb_encrypt(magic, lm_hpw+8, ks);

    memset(lm_hpw+16, 0, 5);


    /* create NT hashed password */

    int   len = strlen(passw);
    char  nt_pw[2*len];
    for (idx=0; idx<len; idx++)
    {
        nt_pw[2*idx]   = passw[idx];
        nt_pw[2*idx+1] = 0;
    }

    unsigned char nt_hpw[21];
    MD4_CTX context;
    MD4Init(&context);
    MD4Update(&context, nt_pw, 2*len);
    MD4Final(nt_hpw, &context);

    memset(nt_hpw+16, 0, 5);


    /* create responses */

    unsigned char lm_resp[24], nt_resp[24];
    calc_resp(lm_hpw, nonce, lm_resp);
    calc_resp(nt_hpw, nonce, nt_resp);

Helpers:

    /*
     * takes a 21 byte array and treats it as 3 56-bit DES keys. The
     * 8 byte plaintext is encrypted with each key and the resulting 24
     * bytes are stored in the results array.
     */
    void calc_resp(unsigned char *keys, unsigned char *plaintext, unsigned char *results)
    {
        des_key_schedule ks;

        setup_des_key(keys, ks);
        des_ecb_encrypt((des_cblock*) plaintext, (des_cblock*) results, ks, DES_ENCRYPT);

        setup_des_key(keys+7, ks);
        des_ecb_encrypt((des_cblock*) plaintext, (des_cblock*) (results+8), ks, DES_ENCRYPT);

        setup_des_key(keys+14, ks);
        des_ecb_encrypt((des_cblock*) plaintext, (des_cblock*) (results+16), ks, DES_ENCRYPT);
    }


    /*
     * turns a 56 bit key into the 64 bit, odd parity key and sets the key.
     * The key schedule ks is also set.
     */
    void setup_des_key(unsigned char key_56[], des_key_schedule ks)
    {
        des_cblock key;

        key[0] = key_56[0];
        key[1] = ((key_56[0] << 7) & 0xFF) | (key_56[1] >> 1);
        key[2] = ((key_56[1] << 6) & 0xFF) | (key_56[2] >> 2);
        key[3] = ((key_56[2] << 5) & 0xFF) | (key_56[3] >> 3);
        key[4] = ((key_56[3] << 4) & 0xFF) | (key_56[4] >> 4);
        key[5] = ((key_56[4] << 3) & 0xFF) | (key_56[5] >> 5);
        key[6] = ((key_56[5] << 2) & 0xFF) | (key_56[6] >> 6);
        key[7] =  (key_56[6] << 1) & 0xFF;

        des_set_odd_parity(&key);
        des_set_key(&key, ks);
    }

Keeping the connection alive

As mentioned above, this scheme authenticates connections, not requests. This manifests itself in that the network connection must be kept alive during the second part of the handshake, i.e. between the receiving of the type-2 message from the server (step 4) and the sending of the type-3 message (step 5). Each time the connection is closed this second part (steps 3 through 6) must be repeated over the new connection (i.e. it's not enough to just keep sending the last type-3 message). Also, once the connection is authenticated, the Authorization header need not be sent anymore while the connection stays open, no matter what resource is accessed.

For implementations wishing to work with M$'s software this means that they must make sure they use either HTTP/1.0 keep-alive's or HTTP/1.1 persistent connections, and that they must be prepared to do the second part of the handshake each time the connection was closed and is reopened. Server implementations must also make sure that HTTP/1.0 responses contain a Content-length header (as otherwise the connection must be closed after the response), and that HTTP/1.1 responses either contain a Content-length header or use the chunked transfer encoding.

Example

Here is an actual example of all the messages. Assume the host name is "LightCity", the NT domain name is "Ursa-Minor", the username is "Zaphod", the password is "Beeblebrox", and the server sends the nonce "SrvNonce". Then the handshake is:

    C -> S   GET ...
    
    S -> C   401 Unauthorized
             WWW-Authenticate: NTLM
    
    C -> S   GET ...
             Authorization: NTLM TlRMTVNTUAABAAAAA7IAAAoACgApAAAACQAJACAAAABMSUdIVENJVFlVUlNBLU1JTk9S
    
    S -> C   401 Unauthorized
             WWW-Authenticate: NTLM TlRMTVNTUAACAAAAAAAAACgAAAABggAAU3J2Tm9uY2UAAAAAAAAAAA==
    
    C -> S   GET ...
             Authorization: NTLM TlRMTVNTUAADAAAAGAAYAHIAAAAYABgAigAAABQAFABAAAAADAAMAFQAAAASABIAYAAAAAAAAACiAAAAAYIAAFUAUgBTAEEALQBNAEkATgBPAFIAWgBhAHAAaABvAGQATABJAEcASABUAEMASQBUAFkArYfKbe/jRoW5xDxHeoxC1gBmfWiS5+iX4OAN4xBKG/IFPwfH3agtPEia6YnhsADT
    
    S -> C   200 Ok

and the unencoded messages are:

Type-1 Message:

       0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
   0:  4e 54 4c 4d 53 53 50 00 01 00 00 00 03 b2 00 00  "NTLMSSP........."
  10:  0a 00 0a 00 29 00 00 00 09 00 09 00 20 00 00 00  "....)....... ..."
  20:  4c 49 47 48 54 43 49 54 59 55 52 53 41 2d 4d 49  "LIGHTCITYURSA-MI"
  30:  4e 4f 52                                         "NOR"

Type-2 Message:

       0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
   0:  4e 54 4c 4d 53 53 50 00 02 00 00 00 00 00 00 00  "NTLMSSP........."
  10:  28 00 00 00 01 82 00 00 53 72 76 4e 6f 6e 63 65  "(.......SrvNonce"
  20:  00 00 00 00 00 00 00 00                          "........"

Type-3 Message:

       0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
   0:  4e 54 4c 4d 53 53 50 00 03 00 00 00 18 00 18 00  "NTLMSSP........."
  10:  72 00 00 00 18 00 18 00 8a 00 00 00 14 00 14 00  "r..............."
  20:  40 00 00 00 0c 00 0c 00 54 00 00 00 12 00 12 00  "@.......T......."
  30:  60 00 00 00 00 00 00 00 a2 00 00 00 01 82 00 00  "`..............."
  40:  55 00 52 00 53 00 41 00 2d 00 4d 00 49 00 4e 00  "U.R.S.A.-.M.I.N."
  50:  4f 00 52 00 5a 00 61 00 70 00 68 00 6f 00 64 00  "O.R.Z.a.p.h.o.d."
  60:  4c 00 49 00 47 00 48 00 54 00 43 00 49 00 54 00  "L.I.G.H.T.C.I.T."
  70:  59 00 ad 87 ca 6d ef e3 46 85 b9 c4 3c 47 7a 8c  "Y....m..F...<Gz."
  80:  42 d6 00 66 7d 68 92 e7 e8 97 e0 e0 0d e3 10 4a  "B..f}h.........J"
  90:  1b f2 05 3f 07 c7 dd a8 2d 3c 48 9a e9 89 e1 b0  "...?....-<H....."
  a0:  00 d3                                            ".."

For reference, the intermediate hashed passwords are:

lm_hpw (LanManager hashed password):

91 90 16 f6 4e c7 b0 0b a2 35 02 8c a5 0c 7a 03 00 00 00 00 00

nt_hpw (NT hashed password):

8c 1b 59 e3 2e 66 6d ad f1 75 74 5f ad 62 c1 33 00 00 00 00 00

Resources

LM authentication in SMB/CIFS

http://www.ubiqx.org/cifs/SMB.html#SMB.8.3

A document on cracking NTLMv2 authentication

http://www.blackhat.com/presentations/win-usa-02/urity-winsec02.ppt

Squid's NLTM authentication project

http://squid.sourceforge.net/ntlm/

Encryption description for Samba

http://de.samba.org/samba/ftp/docs/htmldocs/ENCRYPTION.html

Info on the MSIE security hole

http://oliver.efri.hr/~crv/security/bugs/NT/ie6.html

FAQ: NT Cryptographic Password Attacks & Defences

http://www.ntbugtraq.com/default.asp?sid=1&pid=47&aid=17

M$'s hotfix to disable the sending of the LanManager response

ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/NT40/hotfixes-postSP3/lm-fix

A description of M$'s hotfix

http://www.tryc.on.ca/archives/bugtraq/1997_3/0070.html

Acknowledgements

• Jon Lennard
• Paul Ashton
• Jeremy Allison

本文涉及的几个关键字解释： 

SMB: Server Message Block, 用于共享例如文件、打印机、串口或者是命名管道等用于通讯的抽象对象；
CIFS:  Common Internet File System,  SMB的增强版，Windows 2000/XP实现了该协议；
JCIFS: 一个实现了CIFS的纯Java项目，无须任何的本地库。

JCIFS的网址： http://jcifs.samba.org/

下面我们看一个非常简单的例子，在运行这个例子之前必须准备两台机器A、B，其中我们A是我们程序运行所在的机器，而B则是被访问的机器，仅用B上的Guest用户，而且A当前的用户不能存在于B机器中，也就是说当我们通过资源管理器访问 \\B 的时候，会要求输入用户名以及口令，如下图所示：

这个时候A机器上的程序就不能通过例如 \\B\folder\1.txt 这样的路径来访问B机器上共享文件夹folder中的1.txt文件，也就是说Java中自带的File,FileInputStream类已经不起作用了，不信？ 不信你丫试试

但是借助于JCIFS你就可以很容易的访问到文件1.txt的内容，我们先来看这个简单的例子：

import jcifs.smb.*;

public class Demo{
    public static void main(String[] args) throws Exception{
        //将user和password换成是B机器上的用户名以及口令
        SmbFileInputStream in = new SmbFileInputStream("smb://user:password@B/folder/1.txt" );
        byte[] b = new byte[8192];
        int n;
        while(( n = in.read( b )) > 0 ) {
            System.out.write( b, 0, n );
        }
    }
}

编译并运行这面的例子便可以打印文件 1.txt 的内容。
把上面例子中的密码填写成一个错误的密码再运行程序，便会得到 jcifs.smb.SmbAuthException 异常。

写文件也是一个道理，关于文件的操作JCIFS提供了这么几个类：SmbFile,SmbFileInputStream,SmbFileOutputStream，具体的用户跟Java中对应的类差不多。

JCIFS中文件的URL也就是smb_url，格式为：smb://{user}:{password}@{host}/{path} ，只要填好这个URL，JCIFS就会帮你搞定身份验证的事，粉简单的。

[ 2004-8-10 21:49:00 | By: roof ]

I've been pulled into a little internal project, and one of the requirements is that users should be able to authenticate with their Windows login and password. IIS may or may not be in the picture.

Since the server is a Windows 2000 machine, this turns out to be extremely simple to do thanks to Andy Armstrong's JAAS login modules.

Once you've downloaded the login modules, set your classpath accordingly and make sure that the directory holding NTSystem.dll is in your %PATH% variable. Next, in the "Sample config" folder you'll find a tagish.login file and a java.security.sample file. The last line in the .sample file is significant, and it needs to be in your $JAVA_HOME/jre/lib/security folder (in a file named java.security). You should copy the tagish.login file there as well. If your users will always be logging into the same domain (which is the case in my situation), just set the defaultDomain property in tagish.login, like this:

NTLogin
{
    com.tagish.auth.win32.NTSystemLogin required returnNames=true returnSIDs=false defaultDomain=YOUR_DOMAIN_HERE;
};

Now, all you need to do to use Windows authentication in your webapps is to make one addition to your server.xml file (or to your specific context's definition):

<Realm className="org.apache.catalina.realm.JAASRealm" debug="99"
       appName="NTLogin"
       userClassNames="com.tagish.auth.win32.NTPrincipal"
       roleClassNames="com.tagish.auth.win32.NTPrincipal" />

I'll admit this config is slightly hokey. If you look at the Catalina JAASCallbackHandler (which is hardwired to JAASRealm), the way that I have the realm configured above pretty much counts on the User principal (in effect, the user name) being the first principal returned. This is evil, but it works. It would be nice if either Catalina allowed a pluggable CallbackHandler so that I could take advantage of the NTPrincipal.getType() method or if Andy's code returned subclasses of NTPrincipal like UserPrincipal or GroupPrincipal that I could specify in server.xml.

Once you've got this all configured, the various groups your users belong to equate to role names (so if I belong to an administrators group, my authenticated user will be in role "administrators"), and you can configure security in your webapps using these roles.

二月 17, 2003 04:11 下午 MST Permalink

In addition, while there are many articles on authentication with JAAS [1], [2] , using the API for authorization is relatively undocumented [3]. This paper will show how to use JAAS to secure resources in an MVC architecture.

There are two points of integration with Struts. During the login process and when the client requests a resource from Struts (which will usually be a URL). At each of these points, the application should defer to JAAS classes to perform the action.

This paper will first examine the JAAS infrastructure and then explain how the integration outlined above took place.

Who should read this
This article is for developers who are relatively familiar with web applications and the java security framework. A sample application in Struts is used for the examples [4], but familiarity with Struts is not required. For information on java security, check out Java Security by Scott Oaks. For information on web applications, check out Sun's web site [5]. For information on Struts, check out the Struts web site [6].

Conventions
For the purposes of printing, text that should be on one line will be broken up into more. This will be indicated by a backslash (\) at the end of the line.

Authentication
Login Module
The login module receives information about the user and authenticates the user, thereby verifying that he or she is a valid subject. There are several implementations of login modules currently available. If a custom login module is needed, resources are available [8].

Login Module implementations

Sun provides default implementations for Solaris and NT.

Tagish has several implementations licensed under the GPL [9].

JBoss provides several implementations [10].
Note: For WebLogic 6.1 and Tomcat 3.2, both the jaas.jar and the login module classes needed to be in the non webapp specific classpath.

These login modules are identified by a name in a configuration file and then called by a LoginContext class that JAAS provides. The LoginContext class does not appear to be thread safe--the javadoc states that " a LoginContext should not be used to authenticate more than one Subject. A separate LoginContext should be used to authenticate each different Subject" [11]. Most of these modules expect to be run from an application or on the command line, and thus to be able to interact directly with a user. Since a web application resides on a server, it may be necessary to write an adapter to pull the needed user information from where the web application stores it and place it in a form that the login module can process.

Module Configuration
In addition to putting classes that can do authentication in the correct classpath location, some configuration is required to let the JAAS classes know what type of authentication is possible. JAAS allows complex login schemes [12], however, for most web applications, such complexity is not required. Typically, a username and password will be read from a form, and compared against known server side values. An authentication scheme which verifies a username and password combination against a server side file will be examined below.

Example 1. JAAS login module configuration file

FileLogin
{
            com.tagish.auth.FileLogin required debug=true \
            pwdFile="/usr/local/tomcat/webapps/struts-example/WEB-INF/passwd";
};

In Example 1, the FileLogin authentication scheme has one required module. FileLogin implemented by the com.tagish.auth.FileLogin class. Both the class name and a token indicating the relationship of the module to the scheme are mandatory. Here the required token indicates that the FileLogin module must validate this login or the scheme as a whole fails. It is also possible to pass additional information to the login module in this configuration file. This module needs to know where its password file is located.

Since this configuration file may be located anywhere on the file system, the authentication classes need to be informed where this file is. There are two ways to do this: adding parameters to a JVM wide general configuration file (java.security), or passing the information in on the command line when starting the JVM.

Setting Login Configuration Information Via java.security
This file is where the JVM looks for security related configuration parameters. It is typically located in the JAVA_HOME/jre/lib/security directory. It is possible to have an arbitrary number of login configuration files detailing any number of authentication schemes. These are "read and unioned into one single configuration" [13].

Example 2. java.security entry for login module configuration

login.config.url.1=file:${java.home}/lib/security/tagish.login
login.config.url.2=file:${java.home}/lib/security/struts.login

This entry specifies the location of files containing authentication scheme definitions. Also, note that java system properties may be referenced in java.security.

If the second line looked like login.config.url.3=file:${java.home}/lib/security/struts.login (note the 3), then struts.login would not be searched for login modules. Scanning begins at login.config.url.1 and continues to increment the suffix until no file is found. This is an implementation detail of the default Sun provided authentication classes. For more information, read about the Login Configuration Provider [14].

Setting Login Configuration Via the Command Line
It is also possible to set a java property on the command line when starting the JVM that tells it where to look for the JAAS login scheme configuration file. The property name is java.security.auth.login.config.

Example 3. Setting the location of the login scheme configuration file on the command line

$ java ... \
-Djava.security.auth.login.config==$JAVA_HOME/jre/lib/security/tagish.login ...

This command line overrides any previously set value for the login scheme configuration file location. In typical java fashion, if there was just one = in Example 3, an additional location for the login scheme configuration file would be specified.

Integrating Authentication Into Struts
After the login module is recognized by JAAS, hooks into the web application need to be written. In the example application, an Action class takes a username and password from its Form class and authenticates the user against a database. This is the logical place to hook in the JAAS authentication module.

The Struts example application has a LogonAction class. Initially, the relevant portion of this class looks like this (note that this code is unchanged except to break up lines for ease of printing).

Example 4. Initial LogonAction Authentication

   125          String username = ((LogonForm) form).getUsername();
   126          String password = ((LogonForm) form).getPassword();
   127          Hashtable database = (Hashtable)
   128            servlet.getServletContext().getAttribute( \
                        Constants.DATABASE_KEY \
                        );
   129          if (database == null)
   130              errors.add(ActionErrors.GLOBAL_ERROR,
   131                         new ActionError("error.database.missing"));
   132          else {
   133              user = (User) database.get(username);
   134              if ((user != null) && !user.getPassword().equals(password))
   135                  user = null;
   136              if (user == null)
   137                  errors.add(ActionErrors.GLOBAL_ERROR,
   138                             new ActionError("error.password.mismatch"));
   139          }

On line 125 and 126, the username and password that were submitted on the form are extracted into local variables. The code looks for an authentication database and verifies its existence on lines 127-132. Line 134 is where the actual authentication occurs. If the user exists in the database and the password in the database is the same as the password entered on the form, then the user is authenticated.

This approach works just fine for a sample application. The LogonAction class does all of the authentication in the perform method. But the LogonAction class should be a thin layer deferring the actual work to business objects. In addition, switching the source users are authenticated against requires changes to this class since it is hard coded to expect a password and username. Also, as mentioned in the "Login Module" section, using the JAAS authentication module will be difficult, as most implementations expect some level of user interaction. Putting a business object between the Struts application classes and the JAAS classes can make life easier.

Example 5. Modified LogonAction Authentication

  125          String username = ((LogonForm) form).getUsername();
   126          String password = ((LogonForm) form).getPassword();
   127          Hashtable database = (Hashtable)
   128            servlet.getServletContext().getAttribute(Constants.DATABASE_KEY)
   129          if (database == null)
   130              errors.add(ActionErrors.GLOBAL_ERROR,
   131                         new ActionError("error.database.missing"));
   132          else {
   133              Auth fa = new com.xor.auth.FileAuth(username,password);
   134              if (fa.authenticate()) {
   135                  user = (User) database.get(username);
   136                  HttpSession sess = request.getSession();
   137                  sess.setAttribute(Auth.SUBJECT_SESSION_KEY, fa.getSubject());
   138              }

Lines 125-132 are the same in this example as they were in Example 4. However, rather than the LogonAction class performing the authentication, it defers to a special Auth class. Note that on line 135, the database is still used to get the User object, since the sample application used it in other code.

Auth is a custom interface specifying the contract that the adapter for the JAAS classes must fulfill to interface with web applications in general and this example application in particular. FileAuth is an implementation of that interface which adapts the com.tagish.auth.FileLogin login module specified in Example 1.

Calling the Tagish Authentication Module
The FileAuth class defers to the FileLogin class for almost all its functionality.

Example 6. The authenticate Method of the FileAuth Class

     1     public boolean authenticate() {
     2         try {
     3             lc = new LoginContext("FileLogin", \
                        new MyCallBackHandler(username,password));
     4             lc.login();
     5         } catch (LoginException le) {
     6             return false;
     7         }
     8         return true;
     9     }

On line 3, the LoginContext object is told to look for the FileLogin authentication scheme, and passed a custom callback handler. Normally, callback handlers interact with the user and retrieve information needed for authentication, but the ActionForm class has already done this. In a way, the form is a "call forward" handler, because the request/response paradigm of the web does not fit well with the client/server architecture of which the callback handler is part. The problem is worked around by passing the needed information to the callback handler on instantiation.

On line 4, the LoginContext attempts to login the user via the modules found in the FileLogin authentication scheme. If the login fails for any reason, a LoginException will be thrown, otherwise flow continues normally. A Subject is instantiated by the login module and exposed as a property of the LoginContext object. The Subject is also populated with the Principals associated with that user by the login module.

Cache Subject in Session
After successfully authenticating the user, the Subject should be stored in the HttpSession. (The Subject is small; one Subject with one Principal serialized to a file 337 bytes in size.) This caching allows other parts of the application to perform authorization checks without requiring the user to login again. It also ensures that the other parts of the application are aware that the user has been authenticated, and logs out the user when the HttpSession expires. The storage process is shown on line 137 of Example 5; here the portion of the API of the login module that returns the newly authenticated Subject is examined. To retrieve the subject, the FileAuth class again defers to the LoginContext.

Example 7. The FileAuth Class Exposes the Subject

     1     public Subject getSubject() {
     2         if (lc == null) {
     3             throw new IllegalStateException("either login failed or \
                the authenticate method hasn't been called.");
     5         } else {
     6             return lc.getSubject();
     7         }
     8     }

The getSubject method can only be called after the authenticate method.

Of course, another option would be to store the username and password in the session, and re-authenticate every time. If the Subject were large and the authentication process was fairly fast, this option might be viable.

Authorization
Permissions
Permissions are the heart of authorization; they control access to resources. However, the JAAS permissions are built on top of the existing java security model. This model is very good for controlling access to resources like sockets and files, but has no concept of URLs. Thus, to apply JAAS to a web application, a new permission class must be created.

Create permission class
A custom Permission class that understands URLs must be created. There are two ways to do this.

Extending java.security.BasicPermission is one option. Using this would tie permissions to literal URLs (e.g, one could say that the admin principal should have access to the /admin/index.do page). However, the other option would be better: to create a URLPermission class extended the java.security.Permission class and handled wild cards in a manner similar to the java.io.FilePermission class [15]. Then, one could say that the admin principal should have access to the /admin/ directory and all resources below it.

In either case, since URLs are read only, there is no need for any of these permissions to have an action attribute. On the other hand, it may be useful to specify an attribute of a Permission to determine whether a given URL may only be viewed over a secure connection. For more on extending Permissions in novel manners, see the interesting IBM article titled Extend JAAS for class instance-level authorization [16].

However, since this is a proof of concept, a BasicPermission implementation is fine. For a production system, subclassing Permission would be required.

Access Control Policy Configuration Files
The default configuration for JAAS permissions looks much like the configuration for normal java security. Java security entries consist of a listing of permissions. The permissions can be limited to either a specific code base, or code that has been signed by a specific person, or both. JAAS permission listings can have none, one or both of these elements. However, at least one Principal association is required.

Example 8. Sample JAAS policy file

grant  Principal * * {
  permission com.xor.auth.perm.URLPermission \
  "/struts-example/logoff.do";
};

grant  Principal com.tagish.auth.TypedPrincipal "user" {
  permission com.xor.auth.perm.URLPermission \
  "/struts-example/editRegistration.do";
};

grant  Principal com.tagish.auth.TypedPrincipal "admin" {
  permission com.xor.auth.perm.URLPermission \
  "/struts-example/editRegistration.do";
  permission com.xor.auth.perm.URLPermission \
  "/struts-example/adminMenu.do";
};

The first grant allows everyone to view the logoff.do resource. Anyone with the user Principal is allowed to view /struts-example/editRegistration.do.

At times there will be principals that are granted a superset of the permissions granted to other principals. For example, in Example 8, subjects with the admin principal can view all resources that subject with the user principal can. However, the /struts-example/editRegistration.do URL is listed twice (once in the user section and once in the admin section). It would be nice to be able to avoid duplicating permissions and delineating this relationship between principals, but this is not possible. While more than one principal can be listed for a given set of permissions, if that happens, "[t]he current Subject running the code must have all of the specified Principals in its Principal set to be granted the entry's Permissions" [17]. However, this problem may be dealt with by granting all users with the admin Principal the user Principal as well.

On the other hand, it is possible to have permissions be supersets of other permissions. The implies method of the Permission class can be overridden to provide this behavior. For example, there could be an admin Permission which could imply all other URL permissions.

Note: Example 8 is an example of a file based implementation of the policy. It canbe replaced with a RDBMS implementation by changing the value of the auth.policy.provider variable in the java.security file.
Since the policy file may be located anywhere, JAAS needs to be told where to look for it (this problem is similar to that faced by the authentication configuration setup detailed in Section 2.2. There are two ways to do this: adding parameters to a system wide general configuration file (java.security), or passing the information in as a command line option when starting the JVM.

Note: With WebLogic 6.1, only the command line method worked. Tomcat 3.2 seemed to work with both methods.

Setting the JAAS Policy File Location in the java.security file
This file is where the JVM looks for security related configuration parameters. It is typically located in the JAVA_HOME/jre/lib/security directory. It is possible to have arbitrary numbers of JAAS policy files. These are "read and unioned into one single policy" [18].

Example 9. java.security entry for permission policy configuration

auth.policy.url.1=file:${java.home}/lib/security/struts.policy
auth.policy.url.2=file:${user.home}/.struts.policy

This example should check the policy files in both places. Note also that java system properties can be referenced in the java.security file.

If the second line looked like auth.policy.url.3=file:${user.home}/.struts.policy (note the 3), then the .struts.policy file would not be searched for permission sets. Scanning starts at auth.policy.url.1 and increments the suffix by one until there is no file found. This is an implementation detail of the default Sun permission file parsing class. Obviously, an authorization scheme that used a database would have different behavior.

Setting the JAAS Policy File Location Via the Command Line
It is also possible to set a java property on the command line when starting the JVM that tells it where to look for the JAAS policy file. The property name is java.security.auth.policy.

Example 10. Setting the location of the JAAS policy file on the command line

$ java ... \
-Djava.security.auth.policy==$JAVA_HOME/jre/lib/security/struts.policy ...

This command line overrides any previously set location of the JAAS policy file. If there was only one =, the property would indicate an additional policy file path.

Integrating Authorization into Struts
Now that permissions have been set up and JAAS knows about them, it is time to actually apply them in the context of the application. Every java class that accesses a potentially security sensitive resource needs to check to see if the SecurityManager is running, and if so verify that the calling class is running in a context that allows the access.

Example 11. Typical permission check

Permission p = new FilePermission("/tmp/foo","read");
SecurityManager s = System.getSecurityManager();
if ( s != null) s.checkPermission(p);

The code here is trying to read /tmp/foo. If no SecurityManager is installed (typically via the -Djava.security.manager command line switch), System.getSecurityManager() returns null, and access does not need to be verified.

The web application needs to perform a similar check for each URL that the user is trying to view. In an MVC architecture, the logical place to put such access control is the controller. In Struts, the ActionServlet is the controller. For the sample application the controller class, org.apache.struts.action.ActionServlet, was subclassed, and the process method was overridden.

Installing Access Control Logic into the ActionServlet
First of all, it is important to note that when the ActionServlet is subclassed to provide authorization services, only resources that the ActionServlet controls are protected. Thus, in the example application, only Actions are protected. In a real application, it'd be better to have two methods of access control:

A central servlet which checks authorization before any URL is viewed. For example, all users may need to be logged in before viewing any pages. (If using the 1.3 version of the servlet specification, a filter might be a good choice.)

A JSP tag or other method which may be used to check to see if a user has a given principal before showing content fragments. For example, a menu item may only be accessible to users with the admin permission.
Both of these should delegate to a business class that does the actual security check.

There are at least two pages whose view should not be protected at all: the login page and the login error page. In addition, there are certain security attributes that are peculiar to web applications; for example, some users may need to have all interaction over an SSL connection. The controller needs to do at least three things to provide authorization services for a web application.

Recognize which pages are viewable by every authenticated user and respond accordingly.

Recognize which state, secure or non secure, a request is in and respond accordingly.

Check to see that a user is allowed to view a given URL and respond accordingly.

The ActionServlet Subclass
Example 12. The Overridden process Method

     1    protected void process(HttpServletRequest request, \
            HttpServletResponse response)
     2    throws ServletException, java.io.IOException
     3    {
     4        String loginPage = request.getContextPath()+"/logon.do";
     5        String pageReq = request.getRequestURI();
     6        Permission perm = \
                PermissionFactory.getInstance().getPermission(pageReq);
     7        Subject subject = \
                ((Subject)(request.getSession().getAttribute( \
                    Auth.SUBJECT_SESSION_KEY)));
     8        if (subject == null && \
                (! request.getRequestURI().equals(loginPage))) {
     9            // redirect to login page
    10        } else if (subject == null &&  \
                request.getRequestURI().equals(loginPage)) {
    11            // login page is always permitted
    12             super.process(request,response);
    13
    14        } else {
    15              if ( ! AuthUtils.permitted(subject, perm) ) {
    16              // subject is not permitted; redirect to error page
    17       } else {
    18                 super.process(request,response);
    19             }
    20         }
    21    }

Lines 6 and 7 get needed information including the Permission that represents the URL the user is trying to access (PermissionFactory is a factory class that returns the appropriate Permission), and the cached Subject.

On lines 8-14, the case of the unauthenticated user is handled by redirecting the user to the login page, where access is always allowed (line 12). The reason that this can't be handled by the wildcard grant in Example 8 is that the Subject is null in this case. If the program catches this and creates a new Subject, that Subject still has no Principals and thus is still denied access. For a production system, it's conceivable this case could be handled with an anonymous Principal.

If this is a request for any other resource than the login page, on line 15 the access control class is called. Access is either disallowed, or the process method of the superclass is called.

The ActionServlet should not know about the particulars of the access control; this should instead be handled by a business class. For this example, such a business class was written; it is examined in the next section.

The Access Control Class
This class is similar to the java.security.AccessController class [19], and ends defers to that class eventually (via the SecurityManager). The logic in the class can then be reused anywhere that authorization is needed. The class will basically check whether a Subject has a given Permission.

Example 13. An Abridged Permission Checking Class

     1 package com.xor.auth;
     2
     3 import java.security.*;
     4 import javax.security.auth.*;
     5 import java.util.*;
     6
     7 public class AuthUtils {
     8
     9     static public boolean permitted(Subject subj, final Permission p) {
    10         final SecurityManager sm;
    11         if (System.getSecurityManager() == null) {
    12             sm = new SecurityManager();
    13         } else {
    14             sm = System.getSecurityManager();
    15         }
    16         try {
    17             Subject.doAsPrivileged(subj, new PrivilegedExceptionAction() {
    18                 public Object run() {
    19                     sm.checkPermission(p);
    20                     return null;
    21                 }
    22                 },null);
    23             return true;
    24         } catch (AccessControlException ace) {
    25             return false;
    26         } catch (PrivilegedActionException pae) {
    27             return false;
    28         }
    29     }
    30 }

The example has had all logging, error checking and comments removed for brevity. Production code should, for example, test to see that neither the Permission nor the Subject are null.

Lines 10-15 create a SecurityManager. If the application happens to be one of the rare java applications that run with a SecurityManager installed, then that SecurityManager should be used. If not, a new one is created to check the permissions on line 12.

Lines 16-23 do the actual permission check. If the Subject does not have a Principal which has been granted the Permission, the SecurityManager will throw an exception. For reasons of cleanliness and clarity, this exception is caught and converted to false, which is returned to the calling class. Otherwise, the action is allowed, and true is returned.

The null on line 22 is very important; it tells the SecurityManager to consider this resource access in an isolated context, ignoring the permissions of code currently on the execution stack. For further information, see chapter 5 of Java Security.

Note: If the application is running with a SecurityManager enabled, make certain that the AuthUtils class has been granted the doAsPrivileged AuthPermission in the standard java security policy file. Otherwise, this permission checker will not be able to run; a SecurityException will be thrown when line 17 is reached.

Conclusion
The authentication piece of JAAS seems fairly bulletproof. The idea of pluggable authentication modules is great and the developer can leverage a number of existing modules to ease development.

Using JAAS to leverage the SecurityManager for authorization is entirely commensurate with the java security model. There are resources that only certain users with certain principals should be able to see. Rather than reinvent an access control layer, it makes sense to use the one that java already provides.

However, there are some caveats. This was an extremely simplistic example, and the reader will have noted the number of places where parts of the system need to be replaced to create a production system; these include a new controller, permission class, and policy implementation. In addition, this permission model does not map well to the concept of different protocols used to view a URL.

Definitions
user: a real world entity. It can be another computer system or a human being. This is not represented by an object.

subject: the user as seen by the web application. Subject is the class that represents this concept.

principal: one view of the subject. The API states that it "represents the abstract notion of a principal, which can be used to represent any entity, such as an individual, a corporation, and a login id A Principal is a class that represents a principal" [7]. A principal can be thought of as a role or a group, but those terms have special meaning in J2EE (in the servlet container, for one).

resource: anything in a system to which unlimited access is not granted to all.

permission: access to a resource. The Permission class represents a triplet of resource, action and name. Permissions can be granted to a Principal.

Authentication: the act of verifying that a user is a subject and granting the user certain principals; "who you are."

Authorization: the act of verifying that a user is allowed to access a certain resource; "what you may do."

Authentication module: one method of authenticating a user. Examples include verifying against /etc/passwd and examining the contents of a cookie.

Authentication scheme: a combination of authentication modules.

Current instructions for configuring Tomcat for JAAS-based Windows authentication.
This is the solution for my previous post.

Samba NTLM Authentication: (Get it here.) This package configures exactly as described. I used the example servlet (NtlmHttpAuthExample) included with the package and set up the filter as in the docs. The web.xml file is here.

Notes: I tested on my home (windows) network which does not have a domain controller; I used workgroup authentication and did not test against a PDC. So YMMV.

There are two main drawbacks of this approach:

The first is that the jcifs filter (as currently implemented) does not return group membership information. If your servlet app uses security roles and security constraints, this is a problem since you need some way of getting a user’s group memberships (so the container can map them to security roles). You could get probably around this problem by extending the jcifs library to return group information; this is more work than I planned to invest. Another approach would be to create a second filter that maps user names to group memberships, perhaps using the tomcat-users.xml file. This would be cumbersome and proprietary, but it would probably work.

The second drawback is that NTLM authentication is deprecated in the Windows world. Windows 2000 and 2003 use Kerberos authentication, and only fall back on NTLM when they have to.

For these reasons, I abandoned the Samba NTLM approach and looked at the Tagish / JAAS approach.

JAAS with Tagish SSPI JAAS provider: JAAS with the Tagish SSPI-based login module is the way to go. The Tagish login module is based on the Windows SSPI API, which provides an authentication service for distributed environments using the best available protocol; i.e. it uses Kerberos when that is available and transparently falls back on NTLM when Kerbos is not available. In addition, SSPI returns the group membership information, which is necessary for servlet apps that use security roles and security constraints.

The first step in setting this up is to configure the Tagish login module according to the instructions that come with it. In a nutshell, the steps are as follows:

• Put NTSystem.dll somewhere on your path
• Put tagishauth.jar on your classpath
• Copy the tagish.login file to $JAVA_HOME/jre/lib/security
• Add this line:
  login.config.url.1=file:${java.home}/lib/security/tagish.login
  to your java.security file (in $JAVA_HOME/jre/lib/security)

You can test the configuration using the login.bat file that comes with the Tagish package. If you are on a workgroup, you may need to edit a registry setting to get network authentication to work properly. (I had to.) See this Microsoft KB article for more information; apparently, Windows XP has a “ForceGuest” parameter that forces all network logins for a workgroup to use the guest account.

The second step is to configure Tomcat to use this login module. Here are the steps I used to configure it in Tomcat 5.0.16. Note that the first 4 steps are the same ones for setting up the Tagish login module, just tweaked a little for Tomcat.

• Copy NTSystem.dll to the Tomcat5 bin directory
• Copy tagishauth.jar to the Tomcat5 common/lib directory
• Copy tagish.login to the $JAVA_HOME/jre/lib/security directory. I set the defaultDomain parameter to the name of my server since I’m on a workgroup.
• Add this line:
  login.config.url.1=file:${java.home}/lib/security/tagish.login
  to your java.security file (in $JAVA_HOME/jre/lib/security)
• Configure a JAAS Realm in your Tomcat server.xml file using the following element:
  <Realm className=”org.apache.catalina.realm.JAASRealm” debug=”10″
     appName=”NTLogin”
     userClassNames=”com.tagish.auth.win32.typed.NTUserPrincipal”
     roleClassNames=”com.tagish.auth.win32.typed.NTGroupPrincipal” />
  

The most important thing to remember is that the userClassNames and roleClassNames have to be exactly the same names as the classes that the Tagish login module returns. This is necessary because the Tomcat JAASRealm class compares the classnames of the principal objects with the class names given in the realm configuration. If they do not match exactly, they are ignored.

You can test the configuration using the same NtlmHttpAuthExample servlet that we used to test Samba NTLM. You need a different web.xml that uses security roles; the one I used is here. For this to work, you have to login using an account that is a member of the TESTGROUP group.

To debug it, I had to get log4j working with Tomcat5, which is an adventure in itself. It turns out that the instructions in the Tomcat5 FAQ are incomplete; you need to add commons-logging.jar to common/lib in addition to all the other steps. If you run into trouble, getting log4j debug messages out of the org.apache.catalina.realm package should tell you what is going wrong.

This entry was posted on Sunday, July 18th, 2004 at 9:19 am and is filed under Java. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

16 Responses to “How To Authenticate a Servlet App with Windows Passwords”

1. carmen Says:
   July 19th, 2004 at 8:59 am

   hi,
   I cannot get tagish working! I don’t know what I’m doing wrong. Someone can help me please? I’ve followed the list above step by step
   System: Struts and tomcat on W2000 professional (but also tried same config on W2000 server and it doesn’t work either)
   Thanks

   stack trace:

   19-Jul-2004 17:17:12 org.apache.catalina.realm.JAASRealm authenticate
   WARNING: Login exception authenticating username Administrator
   javax.security.auth.login.LoginException: Error: javax.security.auth.callback.TextInputCallback@da3772 not available to garner authentication information from the user
   at com.tagish.auth.win32.NTSystemLogin.login(NTSystemLogin.java:128)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:324)
   at javax.security.auth.login.LoginContext.invoke(LoginContext.java:675)
   at javax.security.auth.login.LoginContext.access$000(LoginContext.java:129)
   at javax.security.auth.login.LoginContext$4.run(LoginContext.java:610)
   at java.security.AccessController.doPrivileged(Native Method)
   at javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:607)
   at javax.security.auth.login.LoginContext.login(LoginContext.java:534)
   at org.apache.catalina.realm.JAASRealm.authenticate(JAASRealm.java:281)
   at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:129)
   at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:504)
   at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
   at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
   at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
   at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
   at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
   at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
   at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
   at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
   at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
   at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
   at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
   at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:793)
   at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:702)
   at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:571)
   at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:644)
   at java.lang.Thread.run(Thread.java:534)
   19-Jul-2004 17:20:17 org.apache.coyote.http11.Http11Protocol pause
   INFO: Pausing Coyote HTTP/1.1 on http-8080

2. Chris Maeda Says:
   July 19th, 2004 at 10:53 am

   I saw this problem; it was caused by a mistake in the config files. Does Tomcat throw an earlier exception that complains about parsing the tagish login config file? If the parse fails, the callback handler will not be initialized.

3. Manju Panjwani Says:
   August 31st, 2004 at 7:20 am

   I am also facing the same issue.
   WARNING: Login exception authenticating username Administrator
   javax.security.auth.login.LoginException: Error: javax.security.auth.callback.TextInputCallback@da3772 not available to garner authentication information from the user
   at com.tagish.auth.win32.NTSystemLogin.login(NTSystemLogin.java:128)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

   Were you able to resolve the above? Please guide.

4. Louis A Johannson Says:
   September 6th, 2004 at 7:12 pm

   I’ve got the Tagish example working fine where I can use the batch login.bat to test a

   login/authentication. I can also integrate it with JAAS security and have it authenticate me

   against my network in a console application. However, as soon as I try to tie it into

   Tomcat, I get stuck. (I’m trying an web-app example based on BASIC authentication)

   I think my files are in the correct places (I get different errors when they’re missing) and

   I can make my tomcat example web-app work using a different authentication method (the

   tomcat manager’s memory-realm user authentication works fine) and I’ve even done the JAAS

   example to replace the security realm of the tomcat manager app with JAAS.

   The problem I’m getting now is that I get a serious bomb that kills tomcat as soon as I try

   to access the protected directory:

   An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x7BF6256
Function=[Unknown.]
Library=C:\Projects\workspace3\example.Tomcat_NT\lib\NTSystem.dll

   NOTE: We are unable to locate the function name symbol for the error
   just occurred. Please refer to release documentation for possible
   reason and solutions.

   Current Java thread:
at com.tagish.auth.win32.NTSystem.logon(Native Method)
- locked <0x10024d98> (a com.tagish.auth.win32.NTSystem)
at com.tagish.auth.win32.NTSystemLogin.login(NTSystemLogin.java:134)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...


   I’m really rather at a loss as to why this is happening. It ‘feels’ like there is something

   wrong with the tagish module, but if others got it working I really don’t know. Did you have

   to extend it at all? Or wrap it up in an implemented JAAS interface? (but tagish has done

   that already haven’t they?)

   Config:
   Tomcat 5.0.27/28
   Eclipse 3.0
   Sysdeo eclipse/tomcat plugin
   J2SDK 1.4.2_05
   Tagish 1.0.3

   I also tried plugging the tagish module straight into a clean tomcat (without using any of

   my code) to replace the security realm of the manager web-app. The error is slightly

   different here:

   7-Sep-2004 12:46:17 AM org.apache.catalina.realm.JAASRealm authenticate
WARNING: Login exception authenticating username louis
javax.security.auth.login.LoginException: Error: javax.security.auth.callback.Te
xtInputCallback@354749 not available to garner authentication information from t
he user
at com.tagish.auth.win32.NTSystemLogin.login(NTSystemLogin.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:675)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:1
29)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:610)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokeModule(LoginContext.java
:607)
at javax.security.auth.login.LoginContext.login(LoginContext.java:534)
at org.apache.catalina.realm.JAASRealm.authenticate(JAASRealm.java:316)
at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(Bas
icAuthenticator.java:129)


   Does anyone have a clean working example in tomcat they’d be willing to zipup and post?

   My proper email prefix is: louis_a_j
   Suffix: telus.net

5. Louis A. Johannson Says:
   September 6th, 2004 at 7:33 pm

   P.S. As per the following post:
   Tagish and JBOSS
   I’ve tried substituting a default domain into the tagish.login (my workgroup) but that just brought me back to the previous exception which kills tomcat.
   Note: I’ve tried this on both an NT4 domain and on a windows 2000 workgroup with the same results in both.

6. Louis Johannson Says:
   September 7th, 2004 at 8:15 am

   Sorry, the link I included broke:
   http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3837312#3837312

7. Aaron Hawkins Says:
   November 3rd, 2004 at 3:06 pm

   I have the same problem as the #4 comment on this page submited by Louis Johannson. I can authenticate using a console app, but when I try and follow the instructions to authenticate agains Tomcat, my jvm blows up with the same error. It seems that there is a problem with NTSystem.dll. If it is anywhere on my path, my jvm will blow up when I try and use tomcat. If I delete it, then I get errors about it not being found. Has anyone found a solution to this? Any help would be appreciated.

8. Aaron Hawkins Says:
   November 4th, 2004 at 7:19 am

   I have found the solution to the problem described by post #4. The NTSystem.dll doesn’t appear to like a null username. When trying to get this to work with Tomcat, if you use Form based authentication, you can avoid sending a null username, and everything works great.

9. rafal piotrowski Says:
   November 19th, 2004 at 5:50 am

   Hi
   I try to use samba ntlm filter first and I’ve got some problem.
   If I try to open some web page from my web app the internet browser logon dialog always shows.
   How should I configure my Windows XP workstation to eliminate this dialog.

10. mgr Says:
    January 14th, 2005 at 7:25 am

    Hi,
    I have a question about automatic authentication.

    I have a windows 2003 server with active directory. Tomcats and JAAS libraries are correctly installed and configured. When I try to access to the web site I protected by the realm, a login/password is requiered, and I can access to the web site after authentication.

    My question is: is it possible not to have the login/password dialog box if I access to Web site with a computer that belongs to the domain I create and if i’m logged with the correct login/password to have access.
    I would automatically enter to the web site as I’m already authenticated in the Windows session. Is that possible?

    The case is the same if I try locally, on the server. I’m logged with an account who belongs to the domain, and this account belongs to the group I defined in the active directory and in the web.xml file of the web site. But the system ask me the login/password and don’t acces directly to the web site.

    Thanks

11. Mel Riffe Says:
    January 18th, 2005 at 2:23 pm

    I’m starting down this path also and having some troubles. One thing I noticed there is a typo in the instructions. I think you should update the java.security file like so:
    login.config.url.1=file:${java.home}/jre/lib/security/tagish.login

    Plus I added the following to Tagish’s login.bat:
    -Djava.security.auth.login.config=C:\j2sdk1.4.2_06\jre\lib\security\tagish.login

    Next step…authenticating in Tomcat…

    - Mel

12. Trinition Says:
    March 4th, 2005 at 5:09 pm

    I modified the NTSystemLogin source in the Tagish JAAS module to throw a FailedLoginException for a null username or password,a nd not normal BASIC auth works. I presume the null was blowing up in the Tagish NTSYstem.dll or the call it makes to the Win32 API. I shared my update with the Tagish JAAS author, so I’ll see what he thinks.

13. vicky Says:
    April 1st, 2005 at 9:35 am

    Hi, I am trying to use tagish with tomcat 5.0.27 and exactly getting all the same problems mentioned by others. Is there any clear way to use tagish??

    Please advice.
    thanks
    aks

14. jh Says:
    May 4th, 2005 at 2:05 pm

    does this also work on websphere server?

15. Kris Dover Says:
    July 27th, 2005 at 1:47 pm

    Aaron Hawkins, thanks a million. My tomcat 5.0.28 was also crashing with the Basic authentication and i noticed the username null entries in the stdout.log and wondered if that was causing it, but never made an attempt to resolve it using form base authentication until reading your message. seemed very unusual that tomcat’s basic authentication was returning nulls even when the correct username and password were entered on the first try. go figure. Trinition, i haven’t seen an update with your recommended fix, so i might just hack the java code myself. thanks.

16. Joe Says:
    August 4th, 2005 at 9:09 am

    The TextInputCallback is issued when you do not have a defaultdomain=”yourdomain” in your tagish.login file, there is no way for a TextInputCallback to work through the servlet, the source should be changed so that it could parse the domain from the username callback if no default domain is specified, however some people may want to have a text callback for applications instead of servlets.

    The Null username does indeed crash the NTSystem.dll, simply change the login attempt:
    
succeeded = false
ntSystem.logon(username, password, domain); // may throw
succeeded = true;

    to:
    
succeeded = false;
if (username == null || password == null) {
throw new LoginException("Error: " + username == null ? "username" : "password" + ", null, not allowed");
}
ntSystem.logon(username, password, domain); // may throw
succeeded = true;

    and recompile the tagish src to a jar file, deploying it in the Tomcat/bin directory like explained above and everything will work correctly even with Basic auth.

    This is great and all, but I don’t see how tagish is using NTLM, unless you mean it is talking to my domain to get my roles using kerberos or NTLM, it does not however provide the transparent login that jCIFS does. I looked throught the tagish source and don’t see anything in there either, did I misread your article or did I overlook something?

• Subject
• Principals
• Credentials

• LoginContext
• LoginModule
• CallbackHandler
• Callback

• Policy
• AuthPermission
• PrivateCredentialPermission

• com.tagish.auth.DBLogin
• com.tagish.auth.FileLogin
• com.tagish.auth.win32.NTSystemLogin

JAASLogin
{
	com.tagish.auth.DBLogin required 
	dbDriver="sun.jdbc.odbc.JdbcOdbcDriver" dbURL="jdbc:odbc:DBLogin";
};

    Login2 {
       sample.SampleLoginModule required;
       com.sun.security.auth.module.NTLoginModule sufficient;
       com.foo.SmartCard requisite debug=true;
       com.foo.Kerberos optional debug=true;
    };

• required : 验证必须成功, 但是不论成功或失败都继续执行下面的登陆模块, 执行所有之后才丟出验证失败.
• requisite : 验证必须成功, 但是失败就马上回去不做其他验证, 必须成功才继续执行下面的登陆模块.
• sufficient : 验证可以不要成功, 但是成功了就马上回去不做其他验证, 失败可以继续执行其他的登陆模块.
• optional : 验证可以不要成功, 但是不论成功或失败都继续执行下面的登陆模块.

JAASLoginModule
{
com.tagish.auth.DBLogin required dbDriver="net.sourceforge.jtds.jdbc.Driver" 
dbURL="jdbc:jtds:sqlserver://localhost:1433/JAASDB" 
dbUser="sa" 
dbPassword="sa_password"
userTable="Users"
roleTable="Roles"
roleMapTable="RoleMap";
};

<Realm className="org.apache.catalina.realm.JAASRealm"                 
			 appName="JAASLoginModule"
		 userClassNames="com.tagish.auth.TypedPrincipal"       
		 roleClassNames="com.tagish.auth.TypedPrincipal" 
			debug="99"/>

		
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>User Protected</web-resource-name>
      <url-pattern>/protected/*</url-pattern>
      <url-pattern>/protected.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint>
       <role-name>user</role-name>
    </auth-constraint>
  </security-constraint>
  <login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>MyJAASRealm</realm-name>
  </login-config>

在任何一种WEB应用开发中，不论大中小规模的，每个开发者都会遇到一些需要保护程序数据的问题，涉及到用户的LOGIN ID和PASSWORD。那么如何执行验证方式更好呢？实际上，有很多方式来实现。在本文里，我们不会把所有的验证方法都考虑到，我们的目的是让你学会如何以最简单最方便的验证方法来完成。下面将讨论基本的（BASIC）和基于表单的（FORM-BASED）验证方式。我们考虑使用TOMCAT作为WEB SERVER，它通过server.xml和web.xml文件提供基本的和基于表单的验证。JSP页面中的j_security_check 表单(for FORM-based) 需要两个参数：j_username和j_password。它们指定了在SQL数据库中的登陆角色。你能够看到，它的弹性化，可用性和必要性。

第一步，我们要下载TOMCAT和MYSQL，前者用来做WEB SERVER，后者用来做SQL SERVER。还要下载JDBCRealm工具，它在TOMCAT中使用，用来做MYSQL连接器，连接MYSQL数据库的。

我们假设你已经安装了TOMCAT和MYSQL，那么我们开始从SERVER的配置入手了。当然，你还需要安装JAVA的MYSQL连接驱动，我强烈建议只使用稳定的驱动版本，因为在有些情况下，alpha/beta版本的驱动不能正常工作。

下面我们来操作SQL数据库。老实说，MYSQL和TOMCAT是相当好的工具，它们都是跨平台的，不管你的操作系统是WINDOWS还是类似UNIX/LINUX的，它们都能正常运行。因此，不论运行环境，它们的配置过程都是绝对一样的。

MySQL
在命令行中执行mysql 客户端命令，然后输入：

create database weblogin;
这个将为你创建一个weblogin数据库，它将保存用户名和密码以及角色等一切信息。你对数据库所做的任何改变都会直接立即反映出来。比如说添加用户，改变用户密码和角色等。

create table users (
   login varchar (15) not null,
   pass varchar (15) not null,
   primary key (login)
);

我们创建一个users表用来保存用户的LOGIN和PASSWORD：

create tables groups (
   login varchar (15) not null,
   group varchar (15) not null,
   primary key (login, group)
);

如你看到的，我们要在group表里保存login属于哪个group的信息。下面，我们要插于一些数据用来测试使用，并完成MYSQL的配置工作：

insert into users  ('green', 'testpwd');
insert into groups ('green', 'testgroup');

现在，我们创建了一个用户叫green，他的密码是testpwd，他属于testgroup这个用户组。接着，轮到TOMCAT的配置了。

Tomcat
TOMCAT本身并没有能力操作数据库来实现身份验证。但是可以依靠JDBCRealm。下面我们来使用它。

下面我们从TOMCAT的\conf\server.xml文件来开始我们的配置。打开这个文件并找到下面的内容:

<Realm className="org.apache.catalina.realm.MemoryRealm" />
删除这一行，或者用<!-- ... --> 注释掉它,我们要使用JDBCRealm。所以输入下面的内容:

<Realm className="org.apache.catalina.realm.JDBCRealm" debug="99"
   driverName="org.gjt.mm.mysql.Driver"
   connectionURL="jdbc:mysql://localhost/weblogin?user=test&password=test"
   userTable="users" userNameCol="login" userCredCol="pass"
   userRoleTable="groups" roleNameCol="group" />

下面我们对field参数做详细讲解:

debug—这是我们设置的debug参数，数字越高显示信息越详细。
driverName—这个是MYSQL驱动的名字。要确保这个驱动的JAR包在TOMCAT的CLASSPATH中能够找到它。
connectionURL—这个是用来建立JDBC连接的数据库URL。在这个field里，weblogin是我们数据库的名字。user和password 是我们登陆数据库的用户数据。
userTable—一个定义有userNameCol和userCredCol字段的表。
userNameCol和userCredCol—users表里定义的login和pass。
现在，我们完成了配置过程。下面，我们要配置WEB应用程序来被这样一个身份验证方式保护起来。我们要举两个例子。最简单的是基本身份验证方式，然后就是基于表单的身份验证。在第一种情况里，我们尝试访问受保护的数据，将会有一个POP-UP窗口弹出提示你输入你的login和password。在第二种情况里，我们会通过页面的方式来让你通过身份验证。这个页面的内容可以是任意的，这个取决于你要使用怎么样的验证方式了。

基本身份验证方式（BASIC authorization method）
我们假设应用程序在TOMCAT的\webapps\webdemo, 我们要保护所有在admin 子目录里的文件。我们必须打开它的\webapps\webdemo\WEB-INF\web.xml文件，输入下列内容:

<security-constraint>
   <web-resource-collection>
      <web-resource-name>Web Demo</web-resource-name>
      <url-pattern>/admin/*</url-pattern>
   </web-resource-collection>
   <auth-constraint>
      <role-name>testgroup</role-name>
   </auth-constraint>
</security-constraint>
<login-config>
   <auth-method>BASIC</auth-method>
   <realm-name>Web Demo</realm-name>
</login-config>

让我们来看看刚才输入的内容。我们为应用程序创建了一个web-resource-name并映射到login-config 。我们还定义了url-pattern, 它指明你受保护程序的路径。在login-conf中，我们定义了一个BASIC auth-method。

很简单，对吗？不要忘记了，在使改变生效前要停止并重启TOMCAT。

表单身份验证方式（FORM-based authorization method）
对于这种方式，我们仅仅只需要:

修改\webapps\webdemo\WEB-INF\web.xml
创建一个登陆用的JSP页面, 用户将在这里的HTML表单中输入他的登陆ID和密码
创建一个JSP error页面，一旦验证失败，用户将跳到该页面
如果你先尝试使用BASIC验证方式，你只需要改变login-config 为下面那一段代码。否则，你需要输入security-constraint代码段。使用下面的login-config:

<login-config>
   <auth-method>FORM</auth-method>
   <realm-name>Web Demo</realm-name>
   <form-login-config>
      <form-login-page>/admin/login.jsp</form-login-page>
      <form-error-page>/admin/error.jsp</form-error-page>
   </form-login-config>
</login-config>

我们设置表单的auth-method并定义了form-login-config。这个将使得TOMCAT使用 \admin\login.jsp页面来让用户登陆，使用\admin\error.jsp页面来处理登陆失败。

你可以使用任何你想要的出错信息。页面唯一需要的就是下面的HTML表单标签，你要插到页面中：

...
<form method="POST" action="j_security_check">
   <input type="text" name="j_username">
   <input type="text" name="j_password">
   <input type="submit" value="Log in">
</form>
...

布局，风格，或其他所有你喜欢的。这个error页面能够做成任何你想要的。无非就是通知用户，验证失败了。

OK，全部完成了。你需要停止和重启一遍TOMCAT使得改变生效。

© Olexiy Prokhorenko, http://www.7dots.com/resume/
Co-author: Alexander Prohorenko

内存域：MemoryRealm 从XML文件中读取安全验证信息并存入内存中。
JDBC域：JDBCRealm 通过JDBC驱动程序访问存放在数据库中的信息。
数据源域：DataSourceRealm 通过JDBC数据源访问存放在数据库中的信息。
JNDI域：JNDIRealm 通过JNDI provider访问存放在基于LDAP的目录服务器中的安全验证信息。

设置资源安全约束

在web.xml中加入<security-constraint>元素

<security-constraint>
　<display-name>MZT</display-name>
　<web-resource-collection>
　　　<web-resource-name>protected test</web-resource-name>
　　　<url-pattern>/test/*</url-pattern>
　　　<http-method>POST</http-method>
　　　<http-method>GET</http-method>
　</web-resource-collection>
　<auth-constraint>
　　<role-name>mztadmin</role-name>
　</auth-constraint>
</security-constraint>
<login-config>
　<auth-method>BASIC</auth-method>
　<realm-name>test realm</realm-name>
</login-config>

设置JDBC域

<Realm className="org.apache.catalina.realm.JDBCRealm" debug="99"
driverName="org.gjt.mm.mysql.Driver"
connectionURL="jdbc:mysql://localhost/mzt"
connectionName="root" connectionPassword=""
userTable="users" userNameCol="user_name" userCredCol="user_pass"
userRoleTable="user_roles" roleNameCol="role_name" />

<Realm className="org.apache.catalina.realm.DataSourceRealm" debug="99"
dataSourceName="jdbc/tomcatusers"
userTable="users" userNameCol="user_name" userCredCol="user_pass"
userRoleTable="user_roles" roleNameCol="role_name"/>

在MySQL中执行以下SQL语句:

#########

#用户表
create table users(
user_name varchar(15) not null primary key,
user_pass varchar(15) not null
);

#用户角色表
create table user_roles(
user_name varchar(15) not null,
role_name varchar(15) not null,
primary key(user_name, role_name)
);

insert into users values('mzt','test');
insert into user_roles values('mzt','mztadmin');

BASIC and FORM-based Authorization in Your Web Application
By Olexiy & Alexander Prokhorenko

In the development of any, more-or-less big Web application, every developer collides at times with the problem of how to bear certain parts of the application in the protected area and to divide access to them by login and password. How do you carry out authentication? Actually, there are a lot of variants. In this article, we do not present a problem to consider all possibilities; our purpose is to learn how to work with the simplest yet rather convenient method of authorization. We will talk about BASIC and FORM-based authorizations. As a Web server, we will consider Tomcat, which provides BASIC and FORM-based authentication through server.xml and web.xml files; the use of a j_security_check form (for FORM-based) in a JSP page that requires two parameters j_username and j_password; and specifying roles (groups) within the SQL database. As you can see, it's a flexible, useful, and necessary set of capabilities.

To begin with, you need to download Tomcat, which we will use as a Web server and MySQL, which we will use as a SQL server. Also, you need to download the JDBCRealm tool which will be used with Tomcat, and the MySQL Connector/J to use with MySQL.

We assume you have installed Tomcat and MySQL properly, so we can start right from the server's configuration. Of course, you also need to install the MySQL Connector/J driver, and I strongly recommend using only stable releases of the driver because, in some cases, alpha/beta versions of the driver do not work in the given sheaf.

First of all, we will work with the SQL database. Honestly speaking, MySQL, as well as Tomcat, is pretty universal, and doesn't depend on the OS in which you are using it (Windows or Unix-like system), so the process of configuration will be absolutely the same; it doesn't matter where you run it.

MySQL

Execute the mysql client from the installation binary directory and type:

create database weblogin;
This will create the weblogin database in which we will keep user names, passwords, roles?everything. Thus, any changes you have made to the database directly (new users, changed passwords or roles, and so forth) will be reflected immediately.

create table users (
   login varchar (15) not null,
   pass varchar (15) not null,
   primary key (login)
);

We will keep the user's login and password in this users table.

create tables groups (
   login varchar (15) not null,
   group varchar (15) not null,
   primary key (login, group)
);

As you can see, we will keep information about which login belongs to which group in this groups table. Let's fill our tables with some test data and finish the process of MySQL configuration:

insert into users  ('green', 'testpwd');
insert into groups ('green', 'testgroup');

So, we created the user green with the password testpwd in the group testgroup. And now, it's Tomcat's turn to be configured.

Tomcat

Tomcat itself has no ability to work with the database to carry out authentication. However, there is JDBCRealm for these purposes; we are going to use that.

We will start our configuration from Tomcat's \conf\server.xml file. Open this file and find the following string:

<Realm className="org.apache.catalina.realm.MemoryRealm" />
Remove this line or just comment it by using <!-- ... --> Instead of it, we will use JDBCRealm. Type the following:

<Realm className="org.apache.catalina.realm.JDBCRealm" debug="99"
   driverName="org.gjt.mm.mysql.Driver"
   connectionURL="jdbc:mysql://localhost/weblogin?user=test&password=test"
   userTable="users" userNameCol="login" userCredCol="pass"
   userRoleTable="groups" roleNameCol="group" />

We will consider all mentioned fields in a bit more detail:

debug?Here, we set the debug level. A higher number generates more detailed output.
driverName?The name of our MySQL driver. You need to be sure that the driver's JAR file is located in Tomcat's CLASSPATH.
connectionURL?The database URL that is used to establish a JDBC connection. In this field, weblogin is the name of our database; user and password are login data with which you are connecting to the database. In MySQL, such a user is created by default, so you can use it. In case you don't have such a user, you need to create your own user and make it capable of working with your weblogin database.
userTable?A table with at least two fields, defined in userNameCol and userCredCol.
userNameCol and userCredCol?The fields with the name of login field from the users table and pass.
Now, we are at the stage of finishing the configuration process. We need to configure your Web application to be protected with such an authentication. Below, we show examples of two configurations. The simplest is a BASIC authentification method, and a little more original method is a FORM-based one. In the first case at attempting to access the protected area, a pop-up window will appear with the requirement to enter your login and password. In the second case, we will get a page on which we will pass authentification on our defined JSP. The contents of a page can be anything; it should meet only few simple requirements on the contents of a HTML <form> tag. It is up to you what authorization methods you will use.

Basic authorization method

Let's assume that our Web application is located in Tomcat's \webapps\webdemo, and we need to protect all files placed in the admin subdirectory. We need to open its \webapps\webdemo\WEB-INF\web.xml file and type the following text:

<security-constraint>
   <web-resource-collection>
      <web-resource-name>Web Demo</web-resource-name>
      <url-pattern>/admin/*</url-pattern>
   </web-resource-collection>
   <auth-constraint>
      <role-name>testgroup</role-name>
   </auth-constraint>
</security-constraint>
<login-config>
   <auth-method>BASIC</auth-method>
   <realm-name>Web Demo</realm-name>
</login-config>

Let me say a few words about what we just did. We created web-resource-name for our application and mapped login-config to this resource. We defined url-pattern, which has information about which sub-directory of our entire application will be protected, and which role-name is allowed to access the protected area. In login-conf, we defined a BASIC auth-method.

Pretty easy, isn't it? Do not forget to stop and re-start Tomcat to make these our changes work.

FORM-based authorization method

For this method, we will only need to:

Modify \webapps\webdemo\WEB-INF\web.xml
Create a login JSP page, on which the user will get a HTML form to enter his login and password
Create a JSP error page that the user will get if an error happened during authorization
So, let's start from the very beginning. In case you tried the BASIC authorization method first, you need just to change the login-config section to the one listed below. Otherwise, you need to type the security-constraint section from the BASIC method (it's absolutely the same), but use the following login-config:

<login-config>
   <auth-method>FORM</auth-method>
   <realm-name>Web Demo</realm-name>
   <form-login-config>
      <form-login-page>/admin/login.jsp</form-login-page>
      <form-error-page>/admin/error.jsp</form-error-page>
   </form-login-config>
</login-config>

We set the FORM's auth-method and defined the form-login-config section; this will force Tomcat to use the \admin\login.jsp page as the page with the HTML form for the user to sign in, and use \admin\error.jsp in case the login failed.

You can have any login and error screen you like; the only requirement is that HTML <form> should be the following (to be more exact, it should have fields defined as such):

...
<form method="POST" action="j_security_check">
   <input type="text" name="j_username">
   <input type="text" name="j_password">
   <input type="submit" value="Log in">
</form>
...

The layout, styles, or whatever else could be anything you like. The error page could be anything you want; you will need to inform the user that there that something is wrong with the authentication.

That is all. You need to stop and re-start Tomcat to make these changes work.

© Olexiy Prokhorenko, http://www.7dots.com/resume/
Co-author: Alexander Prohorenko

--------------------------------------------------------------------------------
By lanf

应用TOMCAT基于JDBC的的Realm （1）
作（译）者：Lanf From LinuxAID

Realm是一个用户数据库的概念，类似于Unix中的用户群组，它通过用户名和密码来标识一个用户，这个用户属于一定的角色（role）。而一个特殊的web应用资源，可以限定某个角色的用户才被许可访问。这种许可策略，使得web应用的整体权限控制与应用细节相剥离，从而获得更好的可配置性。下面我们通过比较常见的基于数据库，使用直接JDBC连接的Realm的配置使用情况，看看它是如何实现粗粒度的ACL的。

JDBCRealm

JDBCRealm是使用JDBC连接关系数据库的一个Tomcat 4 Realm接口的实现。它可以直接使用你现有的用户数据库表，来获取角色用户的信息，完成验证。你必须满足以下条件：

必须有个有效的数据表，里面有所有你需要通过Realm来认证的用户。这张表必须至少有两个字段，可以用来标示用户名和密码。
需要有一张表来标明用户与角色的对应关系，用户可以有任意个角色，没有角色也是合法的，这是和UNIX用户群组的不同之处。同样这个表也需要两个字段，来映射用户名与角色名的对应关系。
数据库准备

在我们的例子中，我们建两张新表来处理realm的认证。
create table users (
  user_name         varchar(15) not null primary key,
  user_pass         varchar(15) not null
);

create table user_roles (
  user_name         varchar(15) not null,
  role_name         varchar(15) not null,
  primary key (user_name, role_name)
);
 

JDBC驱动

你需要将你的JDBC启动包放在 $CATALINA_HOME/server/lib 目录或者 $CATALINA_HOME/common/lib 目录下，确保Tomcat能通过CLASSPATH找到它。使用mysql数据库的话，你可以使用类似 mm.mysql-2.0.4-bin.jar 的驱动包；Oracle 9i你可以使用ojdbc14.jar等Oracle自带的驱动；PostgreSQL可以在http://jdbc.postgresql.org/ 取得合适的驱动程序。

编辑server.xml

编辑$CATALINA_HOME/conf/server.xml文件，在host里添加如下片段（以MySQL为例）
 <Realm className = 'org.apache.catalina.realm.JDBCRealm' debug='0'
      driverName = 'org.gjt.mm.mysql.Driver'
connectionURL = 'jdbc:mysql://localhost/authority?user=dbuser&password=dbpass'
       userTable='users' userNameCol='user_name' userCredCol='user_pass'
   userRoleTable='user_roles' roleNameCol='role_name'/>

其中 jdbc:mysql://localhost/authority?user=dbuser&password=dbpass 是Mysql的连接串，你可以根据你的需要进行修改。其有关属性介绍如下： 属性 描述
className Realm的实现类，这里必须是 'org.apache.catalina.realm.JDBCRealm'
 
connectionName 数据库用户名
 
connectionPassword 数据库用户的密码
 
connectionURL 数据库的JDBC连接串
 
debug Debug的程度，它和Logger相关配置配合使用，值越高信息越详细，缺省为0
 
digest 存储密码的加密方式，如果不指定则是明文存储。指定为 java.security.MessageDigest 之类的类名则要看数据库里表中用户密码的存放格式。
 
driverName 数据库驱动程序类
 
roleNameCol 角色表的存放角色名的字段名.
 
userCredCol 用户表里存放密码的字段名
 
userNameCol 用户表中存放用户名的字段名
 
userRoleTable 角色表的表名（类似/etc/group）
 
userTable 用户表的表名
 

注意点

如果你对用户表进行了新增操作和修改操作，那么会实时作用于正要进行登陆操作的用户；
用户已经完成登陆后，你对它进行的删除修改操作，并不能实时作用于用户的当前状态，只能在此用户下次登陆的时候生效；（如果是基于表单认证的用户，是在会话结束或者他注销后当前认证失效；如果是基础认证的用户则需要等到当前窗口关闭）
对数据库里那两个表的增删改管理，你需要自行编写合适的业务代码，Tomcat并没有提供标准的实现，这是没有意义的。
编译者注：这部分内容是帮助newbie理解Realm而直接从Realm Configuration HOW-TO中摘译的，是我们完整例子所必须要了解并正确配置的部分，不过似乎没有看到类似的译文，就做了这件累赘的事情。这系列文章对熟手基本没有什么帮助，请见谅。

安装步骤:
1.安装jdk
2.安装tomcat
3.安装mysql
4.安装mysqlcc
5.将驱动包解压,拷贝mysql-connector-java-3.0.14-production-bin.jar到tomcat/common/lib下
或者下载mm.mysql-2.0.14-you-must-unjar-me.jar,解压后拷贝其中的mm.mysql-2.0.14-bin.jar

Tomcat5.0配置 本例使用安装密码 198277
1.配置manager 管理应用程序
在conf/server.xml 中
添加如下

<Service name="Catalina">
...

    <Context path="/manager" debug="0" privileged="true"
             docBase="/usr/local/kinetic/tomcat5/server/webapps/manager">
    </Context>

</Service>

限制ip访问配置
<Context path="/manager" debug="0" privileged="true"
         docBase="/usr/local/kinetic/tomcat5/server/webapps/manager">
         <Valve className="org.apache.catalina.valves.RemoteAddrValve"
                allow="127.0.0.1"/>
</Context>
测试为:http://localhost:8080/manager/html

2.配置JDBCRealm容器管理安全,以mysql-4.0数据库为例
a.拷贝驱动mm.mysql-2.0.14-bin.jar到common/lib/下
b.在数据库ycg中建表
  
 create table users (
  user_name         varchar(15) not null primary key,
  user_pass         varchar(15) not null
);

create table user_roles (
  user_name         varchar(15) not null,
  role_name         varchar(15) not null,
  primary key (user_name, role_name)
);

c.修改server.xml如下(默认数据库为root,无密码,如果有形如:connectionURL="jdbc:mysql://localhost/authority?

user=dbuser&password=dbpass")
      <Realm  className="org.apache.catalina.realm.JDBCRealm" debug="99"
             driverName="org.gjt.mm.mysql.Driver"
          connectionURL="jdbc:mysql://localhost/ycg?user=root"
         connectionName="" connectionPassword=""
              userTable="users" userNameCol="user_name" userCredCol="user_pass"
          userRoleTable="user_roles" roleNameCol="role_name" />

d.在数据库中添加入tomcat的默认配置数据:

+-----------+-----------+
| user_name | role_name |
+-----------+-----------+
| admin     | admin     |
| admin     | manager   |
| both      | role1     |
| both      | tomcat    |
| role1     | role1     |
| tomcat    | tomcat    |
+-----------+-----------+
+-----------+-----------+
| user_name | user_pass |
+-----------+-----------+
| tomcat    | tomcat    |
| both      | tomcat    |
| role1     | tomcat    |
| admin     | 198277    |
+-----------+-----------+

e.启动mysql,启动tomcat,此后tomcat将从数据库中读用户规则认证.默认的conf/tomcat-users.xml失效

3.DBCP的配置
a.设置
             <parameter>
              <name>removeAbandoned</name>
              <value>true</value>
            </parameter>

 可使失效的数据连接重新启用.
配套设置
  
             <parameter>
              <name>removeAbandonedTimeout</name>
              <value>60</value>
            </parameter>
失效时间
如果要写入日志
设置
            <parameter>
              <name>logAbandoned</name>
              <value>true</value>
            </parameter>
以上三个默认都是false
b.以mysql为例,配置数据连接池
c.配置新的用户与数据库,必须设定密码,空密码将导致连接失败
e.
指定root密码:mysqladmin -u root -h localhost password "198277"
(需修改上面的jdbcrealm设置connectionURL="jdbc:mysql://localhost/ycg?user=root&password=198277")
命令mysql进入匿名连接到服务器
密码访问
shell> mysql -h host -u user -p
Enter password: ********

//如果root没有密码,以下是不成功的.(试过了)
 mysql> GRANT ALL PRIVILEGES ON *.* TO javauser@localhost
    ->   IDENTIFIED BY 'javadude' WITH GRANT OPTION;
mysql> create database javatest;
mysql> use javatest;
mysql> create table testdata (
    ->   id int not null auto_increment primary key,
    ->   foo varchar(25),
    ->   bar int);

在conf/server.xml中<host></host>中添加
<Context path="/DBTest" docBase="DBTest"
        debug="5" reloadable="true" crossContext="true">

  <Logger className="org.apache.catalina.logger.FileLogger"
             prefix="localhost_DBTest_log." suffix=".txt"
             timestamp="true"/>

  <Resource name="jdbc/TestDB"
               auth="Container"
               type="javax.sql.DataSource"/>

  <ResourceParams name="jdbc/TestDB">
    <parameter>
      <name>factory</name>
      <value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
    </parameter>

    <!-- Maximum number of dB connections in pool. Make sure you
         configure your mysqld max_connections large enough to handle
         all of your db connections. Set to 0 for no limit.
         -->
    <parameter>
      <name>maxActive</name>
      <value>100</value>
    </parameter>

    <!-- Maximum number of idle dB connections to retain in pool.
         Set to 0 for no limit.
         -->
    <parameter>
      <name>maxIdle</name>
      <value>30</value>
    </parameter>

    <!-- Maximum time to wait for a dB connection to become available
         in ms, in this example 10 seconds. An Exception is thrown if
         this timeout is exceeded.  Set to -1 to wait indefinitely.
         -->
    <parameter>
      <name>maxWait</name>
      <value>10000</value>
    </parameter>

    <!-- MySQL dB username and password for dB connections  -->
    <parameter>
     <name>username</name>
     <value>javauser</value>
    </parameter>
    <parameter>
     <name>password</name>
     <value>javadude</value>
    </parameter>

    <!-- Class name for the old mm.mysql JDBC driver - uncomment this entry and comment next
         if you want to use this driver - we recommend using Connector/J though
    <parameter>
       <name>driverClassName</name>
       <value>org.gjt.mm.mysql.Driver</value>
    </parameter>
     -->
   
    <!-- Class name for the official MySQL Connector/J driver -->
    <parameter>
       <name>driverClassName</name>
       <value>com.mysql.jdbc.Driver</value>
    </parameter>
   
    <!-- The JDBC connection url for connecting to your MySQL dB.
         The autoReconnect=true argument to the url makes sure that the
         mm.mysql JDBC Driver will automatically reconnect if mysqld closed the
         connection.  mysqld by default closes idle connections after 8 hours.
         -->
    <parameter>
      <name>url</name>
      <value>jdbc:mysql://localhost:3306/javatest?autoReconnect=true</value>
    </parameter>

            <parameter>
              <name>removeAbandoned</name>
              <value>true</value>
            </parameter>

             <parameter>
              <name>removeAbandonedTimeout</name>
              <value>60</value>
            </parameter>
            <parameter>
              <name>logAbandoned</name>
              <value>true</value>
            </parameter>
  </ResourceParams>
</Context>

f.在web服务中调用.配置web.xml 如:
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">
  <description>MySQL Test App</description>
  <resource-ref>
      <description>DB Connection</description>
      <res-ref-name>jdbc/TestDB</res-ref-name>
      <res-type>javax.sql.DataSource</res-type>
      <res-auth>Container</res-auth>
  </resource-ref>
</web-app>
g.测试用test.jsp
<%@ taglib uri="http://java.sun.com/jsp/jstl/sql" prefix="sql" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

<sql:query var="rs" dataSource="jdbc/TestDB">
select id, foo, bar from testdata
</sql:query>

<html>
  <head>
    <title>DB Test</title>
  </head>
  <body>

  <h2>Results</h2>
 
<c:forEach var="row" items="${rs.rows}">
    Foo ${row.foo}<br/>
    Bar ${row.bar}<br/>
</c:forEach>

  </body>
</html>

h.新建web应用
下载jakarta-taglibs-standard-1.1.0
copy jstl.jar and standard.jar to your web app's WEB-INF/lib

DBTest/
    WEB-INF/
        web.xml
        lib/
            jstl.jar
            standard.jar
    test.jsp
拷贝到webapps/ 下
i.启动mysql,tomcat
访问:
http://localhost:8080/DBTest/test.jsp
显示:
    Results
    Foo hello
    Bar 12345

4.ssl的配置,以jdk1.4.2为例
a.进入%JAVA_HOME%\bin
运行命令:keytool -genkey -alias tomcat -keyalg RSA
以tomcat 安装密码为198277,ketool设置密码为198277为例
输入keystore密码：  198277
您的名字与姓氏是什么？
  [Unknown]：  ycg
您的组织单位名称是什么？
  [Unknown]：  nju
您的组织名称是什么？
  [Unknown]：  nju
您所在的城市或区域名称是什么？
  [Unknown]：  nanjing
您所在的州或省份名称是什么？
  [Unknown]：  jiangsu
该单位的两字母国家代码是什么
  [Unknown]：  nd
CN=ycg, OU=nju, O=nju, L=nanjing, ST=jiangsu, C=nd 正确吗？
  [否]：  y

输入<tomcat>的主密码
        （如果和 keystore 密码相同，按回车）：  198277
b.在你的D:\Documents and Settings\的当前用户目录下可以找到.keystore文件.将其拷贝到conf/文件夹下.
c.在server.xml 中找到

    <!--
    <Connector port="8443"
               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
               enableLookups="false" disableUploadTimeout="true"
               acceptCount="100" debug="0" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS" />
    -->
    去掉注释

添加配置字段:keystoreFile="/conf/.keystore" keystorePass="198277"
如: <!-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -->
  
    <Connector port="8443"
               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
               enableLookups="false" disableUploadTimeout="true"
               acceptCount="100" debug="0" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS" keystoreFile="/conf/.keystore"
               keystorePass="198277"/>
d.测试为:
https://localhost:8443
e.在自己的程序中添加ssl认证方式为:
在web.xml 中<web-app></web-app>添加
<security-constraint>
<web-resource-collection>
<web-resource-name>Success</web-resource-name>
<url-pattern>/</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>
f.用上提为例就是
修改web.xml 为
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">

    <description>MySQL Test App</description>

<security-constraint>
<web-resource-collection>
<web-resource-name>Success</web-resource-name>
<url-pattern>/</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>

 
  <resource-ref>
      <description>DB Connection</description>
      <res-ref-name>jdbc/TestDB</res-ref-name>
      <res-type>javax.sql.DataSource</res-type>
      <res-auth>Container</res-auth>
  </resource-ref>
</web-app>
访问:
https://localhost:8443/DBTest/test.jsp

g.如果与2配置的jdbcRealm结合起来进行表单认证
先在user_roles表中添加user_name:ycg role_name:web-user
在users表中添加user_name:ycg user_pass:198277

然后在web.xml中添加
<auth-constraint>
<role-name>web-user</role-name>
</auth-constraint>

<login-config>
 <auth-method>BASIC</auth-method>
 <realm-name>My Member Area</realm-name>
</login-config>

修改后的web.xml如:
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">

    <description>MySQL Test App</description>

<security-constraint>
<web-resource-collection>
<web-resource-name>Success</web-resource-name>
<url-pattern>/</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>web-user</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
 <auth-method>BASIC</auth-method>
 <realm-name>My Member Area</realm-name>
</login-config>
 
  <resource-ref>
      <description>DB Connection</description>
      <res-ref-name>jdbc/TestDB</res-ref-name>
      <res-type>javax.sql.DataSource</res-type>
      <res-auth>Container</res-auth>
  </resource-ref>
</web-app>

测试:
http://localhost:8080/DBTest/test.jsp
将通过ssl连接,并进行表单认证.用户密码可在user_roles,和users中添加.

5.中文乱码问题:
mysql 默认编码 iso
tomcat request 传输编码 iso
如果要显示中文
在*.jsp中添加
<head>
<%@ page
language="java"
contentType="text/html; charset=GB18030"
pageEncoding="GB18030"
%>
</head>
如果是数据传输中的乱码(如用servlet从mysql数据库读出的数据)
用以下两个转码函数转码,如果不清楚由哪种编码转成哪种编码,就多尝试.
    //转码GBK转ISO
    public String toISO(String input) {
        try {
                byte[] bytes = input.getBytes("GBK");
                return new String(bytes,"ISO8859-1");
        }catch(Exception ex) {
        }
        return input;

    }
   
    //转码IS0转GBK
    public String toGBK(String input) {
        try {
            byte[] bytes = input.getBytes("ISO8859-1");
            return new String(bytes,"GBK");
        }catch(Exception ex) {
        }
        return input;
    }

以上配置都测试通过.主要参考tomcat5.0的帮助文档.将过程写出来与大家共享.如果发现其中错误,请指出.
欢迎给我来信ycg01@software.nju.edu.cn共同探讨.