Java SCJP 6 Exam Download                  Java SCJP 6 Exam Details

Exam Notes for the Sun Certified Web Component Developer (SCWCD) Exam

6. Designing and Developing Secure Web Applications

6.1. identify correct descriptions or statements about the security issues:

6.1.1. Authentication: Being able to verify the identities of the parties involved
6.1.2. Authorization: Limiting access to resources to a select set of users or programs
6.1.3. Integrity: Being able to verify that the content of the communication is not changed during transmission
6.1.4. Auditing: Keeping a record of resource access that was granted or denied might be useful for audit purposes later. To that end, auditing and logs serve the useful purposes of preventing a break-in or analyzing a break-in post mortem.
6.1.5. Malicious Code:
6.1.6. Web Site Attacks:
6.1.7. Confidentiality: Ensuring that only the parties involved can understand the communication

6.2. Identify deployment descriptor element names, and their structures, that declare the following

6.2.1. <web-app>

<servlet> <servlet-name>secretSalary<servlet-name> <servlet-class>SalaryServer</servlet-class> </servlet>

<security-constraint> ß indicates certain pages in a web app are to be accessed by users in a certain role (role-to-user mappings stored in server-specific format)

<web-resource-collection>

<web-resource-name>protectedResource</web-resource-name>

<url-pattern>/servlet/SalaryServer</url-pattern> ß same wildcards allowed as for servlet mappings

<url-pattern>/servlet/secretSalary</url-pattern>

<http-method>GET</http-method> ß if no methods specified, then all methods are protected

<http-method>POST</http-method>

      </web-resource-collection>

      <auth-constraint>

<role-name>manager</role-name>

<role-name>ceo</role-name>

      </auth-constraint> ß if no role-name, then not viewable by any user;

             if role-name = “*” then viewable by all roles

       <user-data-constraint>

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

 </user-data-constraint> ß optional, indicates SSL security

</security-constraint>

<login-config>

<auth-method>BASIC/DIGEST/FORM/CLIENT-CERT</auth-method>

<realm-name>Default </realm-name> ß optional, only useful for BASIC authentication

<form-login-config> ß optional, only useful for FORM based authentication

<form-login-page>/loginpage.html</form-login-page>

<form-error-page>/errorpage.html</form-error-page>

</form-login-config>

</login-config>

<security-role>

<role-name>manager</role-name>

</security-role> ß not req’d; explicitly declaring the webapp’s roles supports tool-based manipulation of the file

</web-app>

6.3. For each of the following authentication types, identify the correct definition of its mechanism

6.3.1. BASIC
6.3.1.1. web server maintains a db of usernames and passwords, and identifies certain web resources as protected. When these are accessed, web server requests username and password; this information is sent back to the server, which checks it against its database; and either allows or denies access.
6.3.1.2. Disadvantage: provides no confidentiality, no integrity, and only the most basic authentication.
6.3.1.3. Disadvantage: Transmitted passwords are encoded using easily reversable Base64 encoding, unless additional SSL encryption employed.
6.3.1.4. Disadvantage: plus, passwords are often stored on server in clear text
6.3.1.5. Advantage: very easy to set up; useful for low-security environments, e.g. subscription-based online newspaper

6.3.2. DIGEST
6.3.2.1. variation to BASIC scheme; instead of transmitting password over network directly, digest of password used instead, produced by taking a hash of username, password, uri, http method, and a randomly generated nonce value provided by server. Server computes digest as well, and compares with user submitted digest.
6.3.2.2. Advantage: transactions are somewhat more secure than with basic authentication, since each digest is valid for only a single uri request and nonce value.
6.3.2.3. Disadvantage: server must still maintain a database of the original passwords
6.3.2.4. Disadvantage: digest authentication is not supported by very many browsers

6.3.3. FORM
6.3.3.1. the login page must include a form with a POST to the URL "j_security_check" with a username sent as j_username and a password j_password.
6.3.3.2. any time the server receives a request for a protected resource, the server checks if the user has already logged in, e.g. server might look for Principal object in HttpSession object. If Principal found, then roles are checked against security contraints; if Principal not authorized, then client redirected to <form-error-page>
6.3.3.3. Advantage: allows users to enter your site through a well-designed, descriptive and friendly login page
6.3.3.4. Disadvantage: similar to BASIC, password is transmitted in clear text, unless SSL used
6.3.3.5. Disadvantage: similar to BASIC, no standard logout mechanism (calling session.invalidate() may work for FORM, but no guarantees), would need to close browser
6.3.3.6. Disadvantage: error page does not have access to any special information reporting why access was denied or even which page it should point the user at to try again
6.3.3.7. Disadvantage: similar to BASIC, relies on server to authenticate, so only captures username and password, not custom fields e.g. PIN #.

6.3.4. CLIENT-CERT
6.3.4.1. BASIC, even with SSL encryption, does not ensure strong client authentication since anyone could have guessed or gotten hold of client's username and password
6.3.4.2. upon accessing a protected resource, the server requests the client's certificate; the client then sends its signed certificate (many browsers require the client user enter a password before they will send the certificate), and the server verifies the certificate. If browser has no certificate, or if it is not authorized, then access is denied.
6.3.4.3. Advantage: the client will never see a login page, although the browser may prompt for a password to unlock their certificate before it is sent
6.3.4.4. Disadvantages: users must obtain and install signed certificates, servers must maintain a database of all accepted public keys, and servers must support SSL 3.0 in the first place.