Teach Yourself J2EE in 21 Days phần 7 docx

19 0672323842 CH15 3/20/02 9:33 AM Page 653 WEEK DAY 15 Security So far, you have developed your J2EE application without considering security Now you will look at how to add security constraints to your system to prevent loss of privacy or to keep unauthorized clients from accessing data and causing accidental or malicious damage In today’s lesson, you will look at • How the J2EE specification supports the common requirements for a secure system • The common terminology used when discussing system security • Symmetric and asymmetric encryption • Securing a J2EE application using principals and roles • Using declarative security for EJBs and Web pages • Using programmatic security in EJBs and Web pages • Supplying security credentials to an LDAP naming service provider for JNDI 19 0672323842 CH15 3/20/02 9:33 AM Page 654 654 Day 15 Security Overview Security is an essential aspect of most, if not all, enterprise applications However, defining an application as secure is not as easy as it sounds, because the definition of secure can be interpreted in different ways To some users, a Web site is secure if they have to provide a username and password to obtain access to the Web pages As you will see, just because a site requires a user to login does not make it secure Security Terminology Security has many aspects that can be categorized into the following areas: • Authentication • Authorization • Confidentiality • Integrity • Non-repudiation • Auditing Each of these categories is discussed in this section Authentication Authentication means identifying a client as a valid user of the system Identifying a client has two components: • Initially confirming the client’s identity • Authenticating the client each time it accesses the application Initial Identification At its simplest level, initial identification requires a user to simply register with an application without any additional identification More often, a third party, such as the Human Resources department or manager in a company, identifies a user At its most complex level, usually associated with military systems, identification requires background checks to confirm a user’s identity Identified users are registered with the system and granted access to some or all of the facilities provided by the system (see the “Authorization” later in this chapter) 19 0672323842 CH15 3/20/02 9:33 AM Page 655 Security 655 Client Authentication Registered users of an application must identify themselves each time they use the application The most common form of authentication is to give each user a unique name (typically an account or login name) and a password associated with that account Users simply have to provide their account names and passwords to gain access to the application The information identifying a client is usually called the user credentials The most commonly encountered forms of user credentials are as follows: • Account name and password • Swipe cards • Smart cards • Physical identification systems, such as fingerprints and retinal images • Digital certificates Authentication is like the entrance gate to a modern theme park As long as you have a ticket, you are allowed into the park—you have been authenticated But authentication does not necessarily allow you to use all of the rides and facilities in the park The means by which you are allowed access to different parts of the theme park is called authorization Authorization Authorization involves controlling access to capabilities of an application according to the authenticated user’s identity Authorization differentiates between different categories or types of users and grants, or denies them access to different parts of the system Using the theme park analogy again, you may only be authorized to use certain rides Rides may have height, weight, or age restrictions that authorize access to some users and deny access to others Confidentiality Another aspect of security relates not to controlling access to functionality but to ensuring that data is only seen by authorized users In other words, the data remains confidential Maintaining confidentiality is not just a question of authorizing access to the data but also of ensuring unauthorized access either cannot occur, or if it does, that the data remains “secure.” In practical terms, confidentiality is often achieved by encrypting the data so that only authorized users can decrypt and access the data Integrity Ensuring data integrity means preventing deliberate or accidental attempts to modify the data in an unauthorized manner Applying authorization correctly solves most of the data integrity problems concerned with accessing data on a server 15 19 0672323842 CH15 3/20/02 9:33 AM Page 656 656 Day 15 Data transferred across the network must not be changed or corrupted as it is transferred The user must be sure that the data they receive is the data that was transmitted Techniques, such as encryption, checksums, and message digests (see the “Messages Digests and Checksums” section later in today’s lesson), help ensure data integrity across networks Integrity also means that any changes made to a system, are not lost, such as might occur when a server crashes Good auditing practices (see the “Auditing” section later in this chapter) help prevent the loss of changes to persistent data Non-Repudiation Non-repudiation means being able to prove a user did something, even if the user subsequently denies it A simple example is a user with online banking facilities A fraudulent user could transfer money to another bank account and then try to claim this was a spurious transaction and a fault of the banking system With good accounting processes, the bank can prove this was not the case Auditing Auditing is familiar to database users and has the same meaning in security—providing a record of activity Good auditing is an adjunct to supporting non-repudiation and integrity Remember, audit records must themselves be kept secure Common Security Technology Modern software architectures make use of several technologies for supporting system security This section is a quick summary of the key technologies that are used and how then can help support the different aspects of secure systems Symmetric Encryption Data encryption means converting the data so that it can only be decrypted and read by authorized users Data encryption requires an algorithm that is applied to the data to encrypt it Symmetric encryption is so called because it uses the same key to both encrypt and decrypt the data One of the simplest cryptographic techniques is the Caesar cipher (named because Julius Caesar was reported to have used it) The Caesar cipher simply replaces each letter of the alphabet by the letter three positions further on, so that A is replaced by D, B by E, and so on, with the last three letters replaced by the start of the alphabet Figure 15.1 shows the Caesar cipher 19 0672323842 CH15 3/20/02 9:33 AM Page 657 Security FIGURE 15.1 The Caesar cipher 657 ABCDEFGHIJKLMNOPQRSTUVWXYZ DEFGHIJKLMNOPQRSTUVWXYZABC HELLO WORLD KHOOR ZRUOG The Caesar cipher is a specific example of a simple shift substitution cipher when one letter replaces another A different cipher is obtained by shifting the alphabet by more or less than three letters, as shown in Figure 15.2 FIGURE 15.2 KEY A Shift cipher ABCDEFGHIJKLMNOPQRSTUVWXYZ BCDEFGHIJKLMNOPQRSTUVWXYZA CDEFGHIJKLMNOPQRSTUVWXYZAB DEFGHIJKLMNOPQRSTUVWXYZABC 25 ZABCDEFGHIJKLMNOPQRSTUVWXY The number of letters the enciphering alphabet is shifted by is called the cipher key Given an encrypted message, anyone with the key can decipher the message Because the same key is used to encrypt and decrypt the message, this is know as a symmetric encryption algorithm In programming terms, each letter is represented by a number, and the substitution cipher simply adds the key number to the value of each letter to get the encrypted form The resultant number must be adjusted to map the last few letters (X, Y, and Z) onto the first few (A, B, and C) letters This is a very simple algorithm In real applications, symmetric algorithms use sophisticated algorithms with number keys of 56 or 128 bits (approximately 45 decimal digits) The algorithms used are usually well known but, due to the size of the keys used, they cannot be easily reversed In other words, without the key, the original plain text message can only be recovered by applying each possible key in turn As long as the key is a large one and the encryption algorithm is sufficiently robust, the time taken to crack the cipher with a brute-force method attack, such as applying every possible key, can be hundreds of years 15 19 0672323842 CH15 658 3/20/02 9:33 AM Page 658 Day 15 One of the most widely used symmetric encryption algorithms is called DES (Data Encryption Standard) Symmetric encryption is used to ensure data confidentiality Symmetric encryption ensures that only the intended recipients who know the decryption key can recover the original data Asymmetric Encryption Asymmetric encryption uses different algorithms than symmetric encryption and requires the use of two keys One key is used to encrypt the data, and the other is used to decrypt the data The two keys can be very large numbers, with modern systems using numbers of 1024 bits (approximately 140 decimal digits) Asymmetric encryption is called public key encryption due to the way the two keys are used Of the two keys used in asymmetric encryption, one is made public, while the other is kept private to the owner The keys are known, respectively, as the public key and the private key If data is encrypted with the public key, only the owner of the private key can decrypt it This approach is used to ensure data confidentiality but is restricted to supporting only one recipient per message In contrast, using symmetric key encryption allows one message to be distributed to several recipients, as long as each recipient knows the key used to encrypt the message If the private key was known by more than one person, it would undermine the other benefits of using asymmetric encryption (such as non-repudiation) and avoid the need to distribute the cipher key Distributing the keys used in symmetric encryption is a major problem, because the keys have to be distributed in a secure manner An attacker obtaining the keys can decrypt the message to recover the original data Another use of asymmetric encryption is to support non-repudiation If a message is encrypted with the private key, it can only have originated from the key owner Anyone can decrypt the data using the public key with the knowledge that it can only have originated from the owner of the private key This use of asymmetric encryption is the basis of digital signatures Asymmetric encryption is slow compared to symmetric encryption To improve performance, it may be desirable to use symmetric encryption The problem here is how to distribute the encryption key to the recipient securely A common approach is to use symmetric encryption for the data and to pass the encryption key with the data To make this approach secure, the recipient’s public key is used to encrypt the symmetric key passed with the encrypted data The recipient can use his or her private key to recover the key and then decrypt the actual data 19 0672323842 CH15 3/20/02 9:33 AM Page 659 Security This technique enables large volumes of data to be encrypted quickly and, at the same time, distributing the encryption key in a secure manner SSL and HTTPS The Secure Sockets Layer (SSL) is an implementation of public key encryption in TCP/IP networking TCP/IP communication uses a technology called sockets (sometimes called service or port numbers) All standard TCP/IP services advertise themselves on a fixed socket or port—FTP on 21, TCP/IP on 23, HTTP on 80, and so on You have seen socket numbers when using the J2EE RI Web server that runs on port 8000 http://localhost:8000 Ordinary socket communication uses plain (unencrypted) data Any user that can monitor network traffic can read any usernames, passwords, credit card details, bank account information, or anything else passed over the network This is obviously an unacceptable situation from a security point of view One solution to securing confidential data over a network is to encrypt the data within the application This is an inconsistent solution because some applications will be secure while others are not Another solution is to always encrypt all network traffic Because encryption adds an overhead to the network communication, this will affect overall performance and is unnecessary when data does not need to be encrypted The workable solution is to seamlessly provide network encryption only for applications that require secure data transmission Using this approach, any application can encrypt confidential data simply by using the encrypted network communications instead of the usual plain text data transfer Each application decides if encryption is needed but does not have to implement the encryption algorithms SSL is a network encryption layer than can be used by any TCP/IP application The application has to connect by using a secure socket rather than a plain socket, but otherwise, the application remains unchanged Hypertext Transfer Protocol Secure (HTTPS) is the name given to the HTTP protocol when it uses a secure socket The default port used by an HTTPS is 443 When a URL specifies the HTTPS service, the Web browser connects to an HTTP server but uses SSL to encrypt the data All the popular Web browsers indicate on the status line when SSL communication is taking place Typically, an open and closed padlock is used to shown whether data is encrypted Online credit card verification services and banking systems use SSL communication 659 15 19 0672323842 CH15 3/20/02 9:33 AM Page 660 660 Day 15 Checksums and Digests Data integrity is usually achieved by providing checksums or digests of the data The data in a message is subjected to a numerical algorithm that calculates one or more validation numbers that are transmitted with the data The recipient receives the data and applies the same algorithms to the data As long as the recipient’s calculations yield the same numbers as those transmitted with the data, the recipient is reasonably confident that the data is unchanged Checksums use simple algorithms and are primarily intended to detect accidental corruption of data Message digests use sophisticated algorithms that are designed to prevent deliberate changes to data The algorithms used in a message digest generate many digits and are chosen so that it is virtually impossible to change the original data without changing at least one of the digest numbers There are several digest algorithms in use, with Message Digest version (MD5) currently one of the most popular The MD5 specification can be found at http://www.ietf.org/rfc/rfc1321.txt Many applications that can be downloaded from the Web also have an associated signature file A signature file is used to validate the contents of the associated file (the one it signs) Signature files usually contain one or more digests (typically MD5) of the file they are signing After downloading the file, a conscientious user can also download the signature file and check the integrity of the download file by calculating the digest of the file and comparing it to the value in the signature file Programs to calculate digests are widely available on the Internet Digital Certificates Digital certificates are specified by the X509 international standard and define a format for representing public keys and other information about an entity (it could be a user, a program, a company, or anything that has a public key) The official specification for the X.500 Directory Service is available from the International Telecommunications Union (ITU) web site at http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent= TREC-X.509 Digital certificates are often sent with a request for data so that the server can encrypt the data with the recipient’s public key Digital certificates must be signed by a Certification Authority (CA) to prove their validity A signed digital certificate contains a message digest of the certificate encrypted using the CA’s private key Any recipient of the certificate can decrypt the digest using the CA’s public key and verify that the rest of the certificate has not been corrupted or modified 19 0672323842 CH15 3/20/02 9:33 AM Page 661 Security Digital certificates can be used to ensure authentication, confidentiality, and nonrepudiation Caution Valid Digital Certificates have been erroneously issued to individuals spoofing the credentials of trusted companies A Digital Certificate is only as trustworthy as its Certification Authority Security in J2EE The J2EE specification takes a pragmatic approach to security by focusing primarily on authorization within the J2EE environment and integration with security features that already exist in the enterprise You have already seen the J2EE design philosophy of separating roles with the development lifecycle identifying code developers, application assemblers, deployers, and administrators The J2EE security supports this role-based model by using two forms of security: • Declarative security—Declarative security is defined within the application’s deployment descriptor (DD) and authorizes access to J2EE components, such as Web pages, servlets, EJBs, and so on End user tools, such as the J2EE RI deploytool, support declarative security • Programmatic security—Programmatic security is used when declarative security is not sufficient to meet the needs of an application Security-aware components implement the security requirements by using programming constructs The J2EE security specification also requires transparent propagation of security credentials between components In layman’s terms, this means that once clients have logged in to a Web page, they not need to authenticate themselves again for any EJBs accessed from the Web page Also, the authenticated identity of the user remains the same for all components (Web pages, servlets, client applications, and EJBs) J2EE Security Terminology The J2EE security domain is based around the concept of principals, roles, and role references Principals Principals represent authenticated entities, such as users The authentication mechanism is not defined within the J2EE specification, allowing existing authentication schemes to be integrated with a J2EE application 661 15 19 0672323842 CH15 3/20/02 9:33 AM Page 662 662 Day 15 The downside of not defining how users are authenticated means that some parts of the J2EE security features vary between one manufacturer’s implementation and another As the J2EE specification has evolved, additional security requirements have been incorporated to remove the variation between implementations Future versions of the J2EE specification will add additional security-related constraints as the underlying technology matures and standardizes In a simple implementation, a J2EE principal is a user and the principal’s name is the username However, there is no requirement for a particular implementation to map the real usernames onto unique principal names In fact, a principal can represent a group of users rather than an individual user Principal names are only used in programmatic security and are inherently non-portable Wherever possible, J2EE security should be based on roles rather than principals because roles are more portable than principal names Using principals to implement security requires coordination between the developer and the deployer and can restrict the reusability a particular J2EE component Roles Roles are identified by the developer and represent how components in an application will be used Typically, a developer will identify roles, such as user, administrator, manager, and so on, and suggest how the functionality in the application will be used by each identified role A deployer will map principals (real users and groups of users) onto the roles defined in the application The deployer has total control on how the actual security authentication is mapped onto the J2EE application An assembler will combine the roles from many different components to create roles that represent common security requirements across different components Role References Role references are used to map the names used in programmatic security to the roles defined in the deployment descriptor (DD) The developer defines the coded role names used in the code, and the assembler or deployer maps the coded references onto the roles defined in the application The relationships between principals, role references, and roles are shown in Figure 15.3 21 0672323842 CH17 3/20/02 9:32 AM Page 751 Transforming XML Documents Note 751 The text elements representing the new lines between elements are retained in the output This is not a problem when transforming to HTML, but it may be a problem for output formats where newlines are significant XSL defines tags for handling whitespace as discussed in the “Processing White Space” section in today’s lesson Using XSLT in Java Applications The second method of using XSLT is used more often when XML data must be transformed by a Java application JAXP provides a javax.xml.transform.Transformer class that is used to transform XML documents using XSLT A javax.xml.transform.TransformerFactory is used to create a Transformer object A new TransformerFactory object is created by the static newInstance() method in the factory class The following code creates a new TransformerFactory: TransformerFactory factory = TransformerFactory.newInstance(); A Transformer object is created by a newTransformer() method in the factory object and requires a stylesheet as a parameter to the method The stylesheet must be accessed using a javax.xml.transform.stream.Source object A StreamSource object can be constructed from a java.io.InputStream (or a File or Reader object) The following code constructs an XSLT transformer from the stylesheet file called simple.xsl: Source xsl = new StreamSource(new FileInputStream(“simple.xsl”)); Transformer transformer = factory.newTransformer(xsl); The Transformer method transform() is used to transform an XML document using the stylesheet The transform() method takes two parameters—a Source defining the XML document and a javax.xml.transform.stream.Result for the output file A Result can be constructed from a java.io.OutputStream (or a File or Writer object) The following lines will transform the XML document jobs.xml sending the output to the screen: Source xml = new StreamSource(context.getResourceAsStream(“jobs.xml”)); transformer.transform(xml, new StreamResult(System.out)); It’s as simple as that Wrapping this code up as a J2EE servlet is a relatively easy operation, as shown by Listing 17.5 17 21 0672323842 CH17 3/20/02 752 9:32 AM Page 752 Day 17 LISTING 17.5 Full Text of ApplyXSLT.java 1: import javax.servlet.*; 2: import javax.servlet.http.*; 3: import java.io.*; 4: import java.net.*; 5: import java.util.*; 6: import javax.xml.transform.*; 7: import javax.xml.transform.stream.*; 8: 9: public class ApplyXSLT extends HttpServlet { 10: 11: ServletConfig config; 12: 13: public void doGet (HttpServletRequest request, ➥HttpServletResponse response) 14: throws ServletException, IOException, java.net.MalformedURLException 15: { 16: PrintWriter out = response.getWriter(); 17: try { 18: String source = request.getParameter(“source”); 19: int ix = source.lastIndexOf(‘/’); 20: String xmlDoc = source.substring(0,ix); 21: String xslDoc = source.substring(ix); 22: TransformerFactory factory = ➥TransformerFactory.newInstance(); 23: 24: ServletContext context = config.getServletContext(); 25: 26: Source xml = ➥new StreamSource(context.getResourceAsStream(xmlDoc)); 27: Source xsl = ➥new StreamSource(context.getResourceAsStream(xslDoc)); 28: 29: Transformer transformer = factory.newTransformer(xsl); 30: 31: out.println(“Transformed Document”); 32: transformer.transform(xml, new StreamResult(out)); 33: showResource(“XSL Stylesheet”, xslDoc, out); 34: showResource(“XML Source”, xmlDoc, out); 35: out.print(“”); 36: } 37: catch (Exception ex) { 38: out.println(ex); 39: ex.printStackTrace(out); 40: } 41: out.close(); 42: } 43: 21 0672323842 CH17 3/20/02 9:32 AM Page 753 Transforming XML Documents LISTING 17.5 753 Continued 44: private void showResource(String heading, String name, PrintWriter out) ➥throws IOException { 45: out.println(“”+heading+””); 46: BufferedReader in = new BufferedReader(new InputStreamReader( ➥config.getServletContext().getResourceAsStream(name))); 47: String buf; 48: while ((buf=in.readLine())!=null) { 49: StringTokenizer tok = new StringTokenizer(buf,” &’\””,true); 50: while (tok.hasMoreTokens()) { 51: String s = tok.nextToken(); 52: if (s.length()==1) 53: { 54: switch (s.charAt(0)) { 55: case ‘ ‘: out.print(“ ”); break; 56: case ‘’: out.print(“>”); break; 58: case ‘&’: out.print(“&”); break; 59: case ‘\’’: out.print(“'”); break; 60: case ‘“‘: out.print(“"”); break; 61: default: out.print(s); break; 62: } 63: } 64: else 65: out.print(s); 66: } 67: out.print(“”); 68: } 69: out.print(“

”); 70: } 71: 72: public void init(ServletConfig config) throws ServletException { 73: super.init(config); 74: this.config = config; 75: } 76: } The important lines in the servlet in Listing 17.5 are from 18 to 32 On line 18, the servlet reads a request parameter that defines the XML source file and the stylesheet file, which must be defined in the same Web application as the servlet The two filenames are passed as a single parameter called source, each filename being preceded by a forward slash (/) Before looking at the rest of this servlet, a simple HTML form that lets the user invoke this servlet with the example files provided so far is shown in Listing 17.6 17 21 0672323842 CH17 3/20/02 9:32 AM Page 754 754 Day 17 LISTING 17.6 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: Full Text of xsltForm.html XLST Transformations Select an XML document/XSL stylesheet to transform: /job.xml/simple.xsl

You will be able to use this form and servlet to examine most of the example transformations shown today Returning to Listing 17.5, the code in lines 18 to 21 obtains the names for the XML and stylesheet files from the HTTP source parameter Lines 26 and 27 use the getResourceAsStream() method from the ServletContext object to find the named Web application file and return an InputStream object that can be used to read the contents of the file The getResourceAsStream() method hides the real location of the file from the servlet enabling the servlet to be deployed as part of any Web application In Listing 17.5, lines 22 to 32 perform the actual transformation and write the transformed data to the Web page In Lines 33 and 34, the showResource() method returns the text of the original XML data and stylesheet back to the Web browser for the user to view the original XML document, stylesheet, and transformed output on the single page The showResource() method replaces the reserved HTML characters with their replacement string representation To run this demonstration servlet, create a new application called xslt and add the following files to the WAR file: • ApplyXSLT.class • xsltForm.html • jobs.xml • simple.xsl Create a servlet Web application using ApplyXSLT.class as the servlet and give it an alias of /applyXSLT Define the Web application context as /xslt and deploy the application 21 0672323842 CH17 3/20/02 9:32 AM Page 755 Transforming XML Documents 755 You can access the HTML form using the URL http://localhost:8000/xslt/xsltForm.html Select the XML and stylesheet pair you want to view and click the “Submit” button Your screen will look similar to the one shown in Figure 17.1 FIGURE 17.1 Viewing the simple XML transformation 17 To look at the later examples in today’s lesson, you will need to add XML document and stylesheet entries to the list on the HTML form and add the XML document and stylesheet to the xslt Web application So far, you have seen a very simple XLST transformation You will now look in more detail at XSLT and its capabilities XSLT Stylesheets In Listing 17.2, you saw a simple stylesheet that used default transformation rules to remove everything except for the text from an XML document You will now look at how to define your own rules for transforming an XML document Rules are based on matching elements in the XML document and transforming the elements into a new document Text and information from the original XML document can be included or omitted Components from the XML document are matched using the 21 0672323842 CH17 3/20/02 9:32 AM Page 756 756 Day 17 XPath notation defined by the W3C You will learn more about XPath in the “Using XPath with XSLT” section later in today’s lesson, after you have looked at some simple XSLT templates Template Rules The most common XSLT template rules are those for matching and transforming elements The following simple example matches the root node of a document and transforms it into an outline for an HTML document that will be created as you learn more about XSLT’s capabilities Job Details The defines a new template rule in the stylesheet and its match attribute specifies which parts of the XML document will be matched by this rule The root of a document is matched by the forward slash (/); other matching patterns are discussed later in the “Using XPath with XSLT” section The body of the element is output in place of the matched element in the original document In this case, the entire document is replaced by a blank HTML document No other elements in the document will be matched If you want to transform other elements in the original document, you must define additional templates and apply those templates to the body of the matched element The following text adds an element to the rule matching the XML document root: Job Details When this rule is applied to the transformed root element, the body of the root element is scanned for further template matches The output from the other rules is inserted at the point where the element is defined Listing 17.7 shows a simple stylesheet that transforms all of the XML elements into HTML elements 21 0672323842 CH17 3/20/02 9:32 AM Page 757 Transforming XML Documents LISTING 17.7 757 Full Text of basicHTML.xsl 1: 2: 3: 4: 5: Job Details 6: 7: 8: 9: 10:

11: 12: In Listing 17.7, the second rule at lines 9–11 matches every element in the XML document, replaces it with a element, and applies all the templates recursively to the body of the XML element Caution A stylesheet is an XML document, and you must ensure the XML remains valid when outputting HTML In Listing 17.7, on line 10, the text is enclosed inside an HTML paragraph to ensure that the stylesheet remains valid Many authors of HTML simply insert the paragraph

tag at the end of the paragraph This will not work with stylesheets because the unterminated

tag is not well-formed XML Other HTML tags, such as and , must be treated in a similar manner There are alternative solutions to the problem of defining HTML documents inside XSLT stylesheets that are outside the scope of this chapter Listing 17.8 shows the HTML output from applying the basicHTML.xsl stylesheet to the jobs.xml file shown in Listing 17.3 LISTING 17.8 1: 2: 3: 4: 5: 6: 7: 8: 9: Applying basicHTML.xsl to jobs.xml >java org.apache.xalan.xslt.Process -in XML\job.xml -xsl XSL\basicHTML.xsl Job Details

17 21 0672323842 CH17 3/20/02 9:32 AM Page 758 758 Day 17 LISTING 17.8 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: 48: 49: 50: 51: 52: 53: 54: 55: 56: Continued

London

Must like to talk and smoke

Cigar maker

Critic

Washington

Must be honest

Tree surgeon

21 0672323842 CH17 3/20/02 9:32 AM Page 759 Transforming XML Documents 759 In Listing 17.8, the HTML body starts with two STRONG elements corresponding to the root element and the first element The nested XML elements and are output inside tags If you studied Listing 17.8 carefully, you will have seen a element inserted into the output at line The XSL processor has identified the output as an HTML document and, on recognizing the HTML element, has inserted the element to identify the contents of the Web page Note The stylesheet must be well formed XML, so any HTML tags must use consistent letter case names for both the start and end tags HTML is not case sensitive and would allow you to use mismatched names such as This example is invalid in XML and will cause the transformation to fail It is also extremely poor HTML style Now that you have seen how the templates are applied to the body of a tag, you might be wondering how not to apply the templates but still output the text of an element You this by using the tag This tag outputs the text of the currently selected XML element without applying any more templates either to this element or any of its descendents You will use the element when you want to output the text of an XML tag rather than transform it in some way Listing 17.9 shows a more realistic stylesheet for the jobs.xml example file, and Listing 17.10 shows the transformed document LISTING 17.9 Full Text of textHTML.xsl 1: 2: 3: 4: 5: Job Details 6: 7: 8: 9: 10: Jobs 11: 12: 13: New Job:

14: 15: 17 21 0672323842 CH17 3/20/02 9:32 AM Page 760 760 Day 17 LISTING 17.9 16: 17: 18: 19: 20: 21: 22: 23: 24: Continued

Descriptiom:

Location:

Skill:

In Listing 17.9, the leaf elements of , , and are output as text rather than expanded using the template rules Listing 17.9 includes a template for the document root (match=”/”) and the root element (match=’jobSummary”) On Day 16, you learned that the document root is the entire XML document, including the processing instructions and comments outside of the root element Note LISTING 17.10 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: Applying textHTML.xsl to jobs.xml >java org.apache.xalan.xslt.Process -in XML\job.xml -xsl XSL\textHTML.xsl Job Details Jobs New Job:

Location: London

Descriptiom: Must like to talk and smoke

Skill: Cigar maker

Skill: Critic

New Job:

Location: Washington

21 0672323842 CH17 3/20/02 9:32 AM Page 761 Transforming XML Documents LISTING 17.10 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 761 Continued

Descriptiom: Must be honest

Skill: Tree surgeon

Using the tag raises two questions: • What is the text value of an XML element? • What does the select attribute do? These questions are answered in the next two sections Text Representation of XML Elements Every XML node has a textual representation that is used when the tag is defined within a template rule Table 17.1 shows how the textual equivalent of each of the seven XML nodes is obtained TABLE 17.1 Text Values of XML Elements Element Type Description Document root The concatenation of all the text in the document Elements The concatenation of all the text in the body of the element Text The text value of the node, including whitespace Attributes The text value of the attribute, including whitespace Namespaces The namespace URI that is bound to the namespace prefix associated with the node Processing Instructions The text the processing instruction following the target name and including any whitespace Comments The text of the comment between the delimiters As you can see from Table 17.1, every node has a textual equivalent The default rules for a stylesheet only include the text values for the document root, elements, and all text nodes By default, the other four nodes (attributes, namespaces, processing instructions, and comments) are not output Before you can understand the default rules, you will need to study the XPath notation for matching nodes in an XML document 17 21 0672323842 CH17 3/20/02 9:32 AM Page 762 762 Day 17 Using XPath with XSLT XPath is means of identifying nodes within an XML document The W3C identified several aspects of XML that required the ability to identify nodes, for example • Pointers from one XML document to another called XPointer (the equivalent of href in HTML) • Template rules for XSLT stylesheets • Schemas To ensure that the two requirements for identifying nodes share a common syntax, the XPath notation was defined as a separate standard An XPath is a set of patterns that can be used to match nodes within an XML document There are a large number of patterns that can be used to match any part of an XML document Rather than reproduce the entire XPath specification in today’s lesson, you will just study some examples that will help you understand how to use XPath Further information about XPath can be obtained from the WC3 Web site XPath uses the concept of axes and expressions to define a path in the XML document: • Axes define different parts of the XML document structure • Expressions refer to a specific objects within an axis Some of the most frequently used axes have special shortcuts to reduce the amount of typing needed Consider the stylesheet rule you used to match a skill element: Skill:

This matches a child “skill” element using a simple abbreviation The full XPath notation for this would be: The axis is child and the expression is an element with the name skill (the double colon separates the axis from the expression) The current node that a path is defined from is called the context node The child axis is used to identify all nodes that are immediate children of the context node Related axes are • self • parent The current node The immediate parent of the context node 21 0672323842 CH17 3/20/02 9:32 AM Page 763 Transforming XML Documents • descendent • descendent-or-self • ancestor 763 Immediate children of the context node, all the children of those nodes, their children, and so on All descendent nodes and the current context node Any node higher up the node tree that contains context node There are several other axes defined in the XPath notation The match=”.” attribute in the example element, shown previously, is another example of a shortcut The full notation is as follows: Skill:

The function node() refers to the current context node Additional functions are • name() The name of the context node instead of the body of the node • comment() • text() • processing-instruction() Selects a comment node Selects a text node Selects a processing instruction node Some simple XPath expressions are as follows: • self::comment() All comments in the current element • child::text() • descendent::node() • descendent-or-self::skill All the text nodes in the immediate child nodes All the nodes below the context node All the nodes named skill below the current node, including the current node Expressions can be more complex and specify a node hierarchy: • A skill node that is an immediate child of a job node (in full child::job/child::skill) job/skill XPath expressions can be arbitrarily long and can contain the following special expressions: • The immediate parent node defined as parent::node() • // The current node or any descendent as descendent-or-self::node() • * Any node in the specified axis • | Used to provide alternate patterns (one pattern or another) These patterns can be used to identify any node as illustrated by the following examples: • jobSummary//skill jobSummary node Nodes called skill defined anywhere below the 17 21 0672323842 CH17 3/20/02 9:32 AM Page 764 764 Day 17 • jobSummary/*/skill skill nodes defined as children of children of the jobSummary node • skill/ The immediate parent node of a skill node • location|skill • parent::comment()|child::text() A location or skill node Comment nodes in the immediate parent and text nodes in the immediate child • /|* The document root and all elements Attributes can be selected using the attribute axis, which can be abbreviated to @ For example, • attribute::customer An the attribute called customer of any node (not the node itself) • job/@reference job An attribute called reference so long as it is associated with a node In addition to these basic features, XPath supports a powerful matching language supporting variable-like constructs, expressions, and additional functions Now that you have a basic understanding of Xpath, you can look at the default rules for a stylesheet Default Stylesheet Rules There are some default stylesheet rules that apply to the whole XML document unless overridden by specific template rules The first default rule that ensures all elements are processed is as follows: A second rule is used to output the text of text nodes and attributes: A third rule suppresses comments and processing instructions: If an XML element in the source document matches more than one rule, the most specific rule is applied Consequently, rules defined in a stylesheet will override the default rules 21 0672323842 CH17 3/20/02 9:32 AM Page 765 Transforming XML Documents 765 The second default rule specifies that the text value of attributes should be output, but you can see from Listing 17.4 that the attributes in job.xml (Listing 17.3) have not been included Obviously, there is an extra requirement for processing attributes because this rule has never been invoked Processing Attributes Attributes of XML elements are not processed unless a specific rule is defined to process the element’s attributes An attribute is processed by using the rule selecting one or more attributes The third line in the following rule is the one that applies templates to all attributes: This rule matches all elements and applies templates to the child elements and then that element’s attributes It is the second rule with the select=”@*” attribute that ensures that all attributes are output If you only defined the second rule, no output would be produced because the rule had not been applied to elements in the context node With this extra information, you can now revisit the job.xml file and define a stylesheet that will display the job information in an HTML table Listing 17.11 shows a stylesheet that will convert a element to an HTML table LISTING 17.11 Full Text of table.xsl 1: 2: 3: 4: Job ref: / ➥ 5:

6: 7: 8: 9: 10: 11: 12: 13: 17 ... 675 Security The exact mechanism of mapping principals onto roles is not defined in the EJB specification (at least not yet) There are no tags defined in the DD; instead, each J2EE server defines... study Role Mappings Role User Administrator Group j2ee Applicant applicant Customer customer 675 15 19 0 672 323842 CH15 3/20/02 676 9:33 AM Page 676 Day 15 After defining the role mappings for the... references used in the DD onto principals defined in the target authentication domain Configuring J2EE RI Declarative Web Security Web application roles are defined in deploytool using the Roles