81Understanding security

Securing applications

jboss.security:service=XMLLoginConfig </depends> <depends optional-attribute-name="SecurityManagerService"> jboss.security:service=JaasSecurityManager </depends> </mbean> </server>

You can name this file whatever you want, as long as you suffix it with -service.xml (for

example, dynamicloginconfig-service.xml) so that the appropriate JBoss deployer

picks it up and deploys it as an MBean service. You use the AuthConfig attribute

B

specify the name of the file (within your archive) that will contain your security domain definitions. The format of this file is exactly the same as the login-config.xml file we discussed in the last section, so you can copy that into your application archive and whittle it down. In listing 4.2, we configure the dynamic-login config service to look for the

dynamic-login-config.xml file. If this were a WAR file, an EAR file, or any other archive,

JBoss AS would look for it in the META-INF directory of that archive. You enable security

for your application and point it to a security domain defined in this file.

The file that points to the AuthConfig attribute has to be available in the root of

your application’s class path. If you have a WAR file, you have to wrap it in an EAR file

to use dynamic login configuration because the class path for a WAR file isn’t accessi-

ble from outside the WAR file. You can create a JAR file in the EAR (maybe calling it

resource.jar or dynamic-login.jar) that contains this file and any other resource file you may need when configuring dynamic login. Then you configure your applica-

tion.xml file to know about the JAR file.

Now that you’ve learned about configuring security domains, we’ll show how to enable logging for the various security services.

4.1.6 Logging security on the server

By default, security logging is minimal. If you want to log more security information for debugging purposes, you can add the following to your server/xxx/conf/jboss-log4j. xml file:

</category>

Remember to comment out the threshold parameter in the appender that you want the logging messages to appear in. We discussed logging in more detail in chapter 2.

In addition to setting the log4j logging, you can set the following JVM property when

you start JBoss AS to get additional logging related to SSL:

Now that you have a general understanding of what authentication and authorization

are and how JBoss SX enables Java EE security, let’s take an in-depth look at secure

communication.

4.2 Using secure communication

We often need to send data over an open network (for example, the internet), but we

should be aware of three aspects of secure communication: confidentiality,data integrity,

and source integrity. Confidentiality refers to protecting a sent message from being read by anybody else besides the intended recipient(s). To ensure confidentiality, the sender often encrypts messages that the recipient then decrypts. Data integrity refers to a message recipient’s confidence that the message she receives wasn’t manipulated while in transport. Encrypted communication protocols can also ensure data integrity.

Source integrity gives assurance to a message recipient that the message she receives is indeed from the sender that she thinks she’s communicating with and not somebody else who’s posing as the sender. Source integrity can be protected by using a reliable third party that assigns certificates to different people and organizations. A person who wants other people to trust him can obtain a certificate and send it to other parties who can verify the certificate owner’s identity by asking the trusted third party, which is usually a certificate authority.

It’s important to remember that the source that has integrity may be a machine, meaning that a non-trusted user on a trusted machine could gain access to things that he shouldn’t.

Secure protocols such as Transport Layer Security (TLS) or Secure Sockets Layer (SSL)

can be used to provide these three aspects of secure communication. These protocols use a combination of public and private key cryptography and digital certificates. In this section, we discuss mechanics and configuration behind these forms of cryptography.

NOTE TLS is a newer specification that’s meant to be a replacement for SSL.

TLS 1.0 is similar to SSL 3.0. TLS is starting to gain in acceptance and usage,

but SSL is still a more dominant and well-known protocol. Because more

people recognize the initialism SSL, from here on, we refer to both SSL

and TLS as SSL.

Let’s start by talking about the two major categories of encryption: symmetric encryption and asymmetric encryption.

4.2.1 Understanding symmetric and asymmetric encryption

Encryption is easier to understand when you consider the analogy of a lock and key. Let’s say that you have a secret message that you want to mail to a friend. You put the message in a box that can be secured with a padlock. If you and your friend both have keys to the same lock, you can put the lock on the box, lock it, and send it to your

friend. After receiving the box, she can open it with her key. This is how symmetric

encryption works. A message is encrypted with a secret key and decrypted with the same key. As long as the key isn’t compromised, the two parties can communicate securely. WARNING

In document JBoss in Action Configuring the JBoss Application Server pdf (Page 109-111)