6. ANEXOS
6.15. Anexo 15: Normativa de la Comunidad de Madrid
4.1.1 Understanding application security
To understand how authentication, authorization, and secure communication fit into an enterprise application, let’s look at an example of a web-based retail banking appli- cation. Figure 4.1 shows a typical request flow through the application.
Most people have accessed a web-based bank before, so this shouldn’t look too unfamiliar. In the diagram, we have a bank customer (let’s call her Melissa) who’s try-
ing to access her bank account through her bank’s secure Java EE-enabled website. In
order for customers to be able to log into the bank’s website without worrying about phishing schemes or man-in-the-middle attacks, the bank has purchased a secure pub-
lic-key certificate from a trusted certificate authority (CA). Melissa accesses the bank web-
site and clicks on a link that should take her to her account summary
B
. This linkmight be something like https://www.jbossbank.com/acctSummary.
Because the page is accessed via a secured protocol (HTTPS), the server sends its
secure certificate to Melissa’s web browser. Melissa’s browser, like all major browsers, has a list of well-known certificate authorities. On receiving the bank’s certificate, her browser turns around and asks the trusted certificate authorities if the certificate
belongs to the bank
C
. Assuming that one of the certificate authorities acknowledgesthe authenticity of the bank’s certificate, Melissa’s browser tries to forward her to the account summary page she originally requested. As far as Melissa is concerned, this all
happens behind the scenes. She can now trust that she’s accessing her bank and that
nobody can intercept her communication with her bank. Also, as long as she accesses the bank over the secure protocol, all her communications are transferred over a secure channel.
Figure 4.1 Multitier web application that utilizes authentication, authorization, and secure communication
Now that Melissa knows that she can trust the bank, the bank needs to know if it can
trust her. The URL for the account summary page is secured with form-based authenti-
cation. Users also must be a part of the AccountHolder role before accessing the page. Before Melissa can access the account summary page, her request is intercepted by
the JBoss Web Server web container. The container realizes that the URL that she’s
accessing is secured, so it checks with the security framework
D
to see if Melissa isalready logged in. After realizing that she’s not, a login form is sent back to Melissa, prompting her for her username and password.
When Melissa types in her credentials and submits the form, the web container receives the form submission and passes Melissa’s credentials to the application server’s
security framework
D
. The security framework accesses security information from adatabase
E
, which it queries to determine whether or not Melissa can access to theresource she’s requesting. First, the security framework should authenticate Melissa, com-
paring the password she supplies against a known password to see if she should be
granted access to the system at all. Then, the security framework should authorize Mel-
issa, determining if her username is associated with a role that can access the resource. Everything matches up, so the security framework returns control back to the web container. Now that Melissa’s credentials have been verified, the web container for-
wards her request to the resource associated with the URL for the account summary.
The account summary page is implemented as a servlet. In order for the servlet to ren- der Melissa’s account summary information, it needs to access her account informa-
tion. The servlet makes a call to the getAccountSummary(Useru) method on a session
EJB called Account, which runs in the EJB container
F
. Because the EJB containerruns locally, the servlet automatically propagates the security credentials.
Like the servlet, this EJB method only allows access to users with the AccountHolder
role. The EJB server accesses the JBoss SX security framework
G
to determine if Melissais authenticated and authorized to access the resources. Again, access to the EJB
method succeeds, and Melissa’s account information loads from the application data-
base
H
. After the account summary loads, control returns to the servlet, which rendersthe output and sends it back to Melissa, still over a secure channel.
The three main areas of application security that we see here are authentication, authorization, and secure communication. In this section, we discuss authentication
and authorization in more detail. We also discuss how to configure JBoss SX and how
to enable security logging. Secure communication requires more discussion and is covered in more depth in section 4.2. Let’s take a closer look at authentication.
4.1.2 Understanding authentication
Authentication is the process by which a system verifies the identity of a user. In the example, when Melissa tries to access her bank’s website, the site asks her for her user- name and password. This procedure allows the site to authenticate her as a valid user. But humans aren’t the only ones whose identities are validated by software applica- tions; programs can also try to authenticate against an application. In security par-
77