Anexo 20: Normativa de la Comunidad Valenciana

Mutual authentication isn’t commonly found in publicly accessible web sites because all users of a website would have to create or obtain their own certificates and set them up in their browsers. Mutual authentication is sometimes used in intranet applications and in applications that need added assurance that requests coming into the system

originate from a safe source. For example, a bank may implement SSL mutual authen-

tication in an application that allows other banks to submit transactions over the inter- net. Although the authentication could be done by password, the certificate gives the bank more confidence about the identity of the client and also ensures that the infor- mation is encrypted before it’s sent over the internet.

Many internal corporate applications use mutual authentication to allow employees to securely access their applications over the internet. In many cases, the company is its

own CA and assigns keys to each employee who needs access to the internal systems.

So far, we’ve talked about mutual authentication at the protocol level, meaning

that the client and server authenticate each other using their CAs when the protocol-

level handshaking occurs. But this type of protocol authentication is different from the application-level authentication we talked about in section 4.1.2. The server can use the client’s certificate as a credential for application-level authentication. Building on top of the protocol-level mutual authentication, the server can read the informa- tion off the client certificate and compare it against its own database of users. This is often called client-certificate authentication.

The bottom diagram in figure 4.8 shows that client-certificate authentication requires both the client and the server to have certificates. The diagram also shows that the server must have a truststore that contains all the public certificates for the cli- ents whom it wants to trust to gain access to its applications. This truststore is a secu-

rity data source that’s pointed to by a JBoss SX login module in the same fashion that

you’d point to a database or an LDAP server. We talk about the login module that you

use to configure this in section 4.3.4. You also learn how to configure client-certificate authentication from end to end for a web application in chapter 6 (section 6.5).

What are the tradeoffs between password-based client authentication and client- certificate authentication? You can argue whether authenticating against information on a certificate provides any protection over authenticating against a user-provided password. If the client’s certificate is already available in the web browser or applica- tion, then the server can automatically get the certificate and authenticate the user. The user doesn’t have to stop and type in a password. Client-certificate authentication provides you with an auto-login mechanism.

But, replacing password-based authentication with client-certificate authentication isn’t always a good idea. What if somebody steals the user’s computer with the certifi- cate on it? The thief wouldn’t not need a password to gain access to the information the true owner of the certificate had access to. What if somebody sneaks into your office and runs a few transactions while you’re out to lunch? What if somebody hacks into a bank’s server that has a client certificate set up to talk to another bank’s transac- tion system? Again, the hacker would have immediate access without the need for manual authentication. These are all considerations you have to make before choos- ing client-certificate authentication over password-based authentication.

We’ve talked about how to configure security domains, and we’ve also talked about how to create certificates. Often, you’ll need to bring these two together to create an

SSL-aware security domain.

4.2.6 Configuring an SSL-aware security domain

JBoss Web Server has built-in support for SSL through its HTTP connector, so configur-

ing SSL for web applications is relatively simple as we see in chapter 6 (section 6.4). But,

if you want to authenticate clients based on their certificate information as we discuss

in chapter 6 (section 6.5), then you’ll have to define an SSL-aware security domain.

Unfortunately, you can’t specify an SSL-aware security domain in the login-config.

xml file as we did for non-SSL security domains in section 4.1.4. To enable an SSL-aware

security domain, you must also define an MBean instance of JaasSecurityDomain that

points to a truststore. Figure 4.9 shows you the relationship between the JassSecurity-

Domain MBean and the security domain defined in the login-config.xml file.

To define the JassSecurityDomainMBean, create a file that ends in -service.xml and

put it in the server/xxx/deploy directory. We talked about how services are defined using *-service.xml files in chapter 2 (section 2.2). Listing 4.3 shows what the contents of this file look like.

<server> <mbean code="org.jboss.security.plugins.JaasSecurityDomain" name="jboss.security:service=MySecurityDomain"> <constructor> <arg type="java.lang.String" value="my-security-domain" /> </constructor>

Listing 4.3 An SSL-aware security domain defined as an MBean

Figure 4.9 The relationship between the JaasSecurityDomain MBean, the truststore, the security domain, and the security datastore

91