77Understanding security

identity on another system. A principal provides one or more forms of identification

known as credentials. Possible credentials include passwords, certificates, biometric

data, smart cards, physical tokens, or any other reliable form of identification.

In figure 4.2, we show a user named Joe trying to access a web resource. He pro-

vides his username and password. The server calls the JBoss SX framework to authenti-

cate the user. The JBoss SX framework then tries to load Joe’s password from a security

data source and compare it to the password he provided. The security framework doesn’t authenticate the user if his username doesn’t exist in the data source or if his password doesn’t match the one in the data source.

Security data can be kept in different data sources, so JBoss SX has different login

modules that can read security information from different locations such as a database

or an LDAP server. We discuss the different login modules that are available in JBoss

SX in section 4.3.

Many cryptographic protocols provide both clients and the server with the ability to authenticate each other by using public certificates as a credential. We give you an overview of how this works when we discuss secure communication in section 4.2.

Now, let’s take a closer look at authorization.

4.1.3 Understanding authorization

Authorization is the process of verifying that a principal has sufficient privileges to access an application resource. For example, a user may have access to a document management system but may not have access to look at particular documents put into the system by other users. Authorization is often achieved by assigning one or more roles to a principal and then associating one or more roles with a component or resource that a principal might want to access. When the principal tries to access the component, the system looks at the roles allowed to access the component and the roles assigned to the principal. If the principal has one of the roles assigned to the component, then he can access the component; otherwise, the principal can’t access the component. This process is called role-based authorization.

Figure 4.3 shows how authorization works when our friend Joe tries to access the administrator page on the web application he’s using.

Figure 4.2 The application server authenticates a principal when it tries to access a secured resource.

Joe is trying to access the administrator page, which is configured to require a role of

admin. The web container asks the JBoss SX login module whether Joe (who has already been authenticated) can access the page. The login module goes to the authorization

data source, loads all of Joe’s roles, and then asserts that one of those roles is admin.

Java EE defines declarative, role-based authorization for standard component tech-

nologies such as servlet, JSP, and EJB. Declarative authorization means that you can

assign roles to components via configuration without the need to write any code. As

you’ll learn in chapter 7, access to EJB methods is restricted by roles defined in either

annotations or a deployment descriptor. Web applications can define role access for

particular URLs in deployment descriptors as well, as we discuss in chapter 6.

There are certain situations where role-based security doesn’t cut it. This fact becomes evident when the security you want to apply depends on the context of the request that the user sends. Applying security based on information in the request is

often called context-based security, or programmatic security. For example, you want to

allow a bank employee to enter deposits under $10,000 dollars, but anything over $10,000 would require manager’s approval. This type of security often involves writing code and is considered part of the business functionality of your software. Unfortu- nately, there’s a lot of information to cover on role-based security, so we don’t discuss context-based security. You can implement context-based security in several ways for

each of the different component models. For EJBs, you can use JBoss SX security prox-

ies or EJB3 interceptors. For web applications, you can use servlet filters, custom

valves, or interceptors.

Now that you have some background on how authentication and authorization work, let’s discuss how you can configure applications to enable these aspects of security.

4.1.4 Configuring security

Each Java EE component or resource has a different mechanism for defining security.

For example, you can use a web application’s standard deployment descriptor to

define which authentication policy should be used and to secure individual URLs by

defining roles that have permission to access them. This definition of what method to use and what should be secured is defined in each component’s standard deployment

Figure 4.3 The steps involved in authorizing a user

79