Cams gives you all the security features Tomcat does, and a whole lot more. Find out more about Cams by reading the
Cams Overview and the Access Management white paper. We recommend that you also take the Cams Tour to interactively learn about Cams and web security in general.
Therefore, a J2EE compliant servlet container is required to track authentication information at the container level (rather than at the web application level). Tomcat enables users authenticated for one web application to access other web applications managed by the same container. However, login configurations must still be specified for each web application, which, depending upon the number of web applications can be difficult to manage (Tomcat also allows each web application to define its own realm). Additionally, Tomcat single sign-on does not address multiple Tomcat servers, other web servers such as Apache, or an application server like JBoss.
Specifying Security Constraints
Deployment descriptor
web-resource-collection - A set of URL patterns and HTTP methods that describe a set of resources to be protected. All requests that contain a URL pattern matched in a web resource collection are subject to the constraint.
auth-constraint - A set of security roles (one or more) to which a user must belong to be granted access to resources matched by the web resource collection.
user-data-constraint - Describes integrity and confidentiality requirements for the transport layer of the client server.
Hence, the web resource collection defines the resources, the authorization constraint defines the roles to which a user can belong to access the resources, and the data constraints defines if HTTPS should be required.
Enhancing Tomcat Security with Cams
When you arrive at the boundary of Tomcat security, you'll discover that it is generally limited by the scope of the servlet specification and J2EE security. Consequently, Tomcat will not meet the security needs of most heterogenous, multi-server environments. The good news is that you have the Tomcat source and can write security code and implement security in servlets to customize Tomcat. The bad news is that you probably don't have the time, budget, expertise, or even desire to write security code.
In addition, embedding low-level security code within applications is considered to be bad practice.
The Cafésoft Access Management System is designed to pickup where Tomcat security stops. Cams flexibly meets the needs of the enterprise by providing a complete web access managment system which spans servers and tiers in a web farm. Cams provides the same security features Tomcat does and more.
From a high-level, you should consider using Cams with Tomcat when you have any of the following needs:
Cams offers many unique features that might more closely adhear to your security needs. The following tables show a feature by feature comparison of Tomcat security with and without Cams.
Authentication
By default, you do not need to authenticate to access Tomcat resources. Authentication is needed only when specified in the deployment descriptor with the auth-constrain element. You use a web client (typically a web browser) to authenticate with Tomcat using one of the following mechanisms:
HTTP Basic Authentication
HTTP Digest Authentication
Form Based Authentication
HTTPS Client Authentication
HTTP Basic Authentication
When your browser prompts you for a username and password in a dialog box, you are using HTTP basic authentication to logon to a web server. This is also know as browser-based authentication because the web server requests the browser to authenticate you through the HTTP 1.0 protocol. In the dialog box, you also see the name of a realm to which you will be authenticated. The realm does not necessarily reflect a security policy domain, which is also referred to as a realm. Think of an HTTP basic authentication realm as a "database" of usernames and passwords that identify valid users of a web application (or set of web applications), plus a list of the roles associated with each valid user.
Once you enter your username and password, they are base64 encoded and sent by the browser to Tomcat (for both secure and non-secure resources). Tomcat authenticates you, and then reauthenticates each subsequent request against the specified realm. You cannot logout as your username and password remain in browser memory until you exit. Hence, you must exit the browser to "logout".
Because the username and password are not encrypted, and the target server's identity is not authenticated by the browser, basic authentication alone is not secure. You can improve security by using a secure transport mechanism such as HTTPS, or security at the network level such as a VPN. However, if you switch to HTTP (after authenticating with basic authentication and HTTPS), your browser continues to send your username and password with each subsequent request in cleartext until you exit.
HTTP Digest Authentication
HTTP digest authentication is also performed by the browser upon request by the web server and based on a username, password, and realm. However, in this case your password is digested with the secure MD5 algorithm before it is sent by the browser.
You can specify in Tomcat's
Because your password is digested, HTTP digest authentication is more secure than basic. However, it does suffer from the same security issues as basic authentication. As it is not supported by popular browsers, HTTP digest authentication is not required by the servlet specification, but it is implemented by Tomcat. As with basic authentication, your credentials are stored in the browser's memory until it is exited.
This is the most popular web authentication mechanism in use. It provides the application developer with the greatest control over the look and feel of the “login screen”, enables closing of user sessions without exiting the browser, and is more secure than basic authentication.
The web application deployment descriptor contains elements to specify a "login form" and an "error page". The HTML login form must contain fields for entering a username and a password, which must be named "j_username" and "j_password", respectively. When you attempt to access a protected resource, Tomcat checks if you are authenticated. If not, the following steps occur:
Java XML
3) On calling DOMHelloWorld
The main method of DOMHelloWorld.java will check that the filenameof the xml file has been provided as an argument.
public static void main(String[] args) { if (args.length != 1) { System.out.println("usage: java DOMHelloWorld hello.xml"); System.exit(0); }
String xmlfilename = args[0];
} 4) Parsing the XML documentjava.io.IOException;
First we must create an instance of the parser (vendor specific parser). This is the same parser we imported earlier in step 2.
DOMParser xmlparser = new DOMParser();
5) Parse the xml file.
This is really easy because the parser does it for you.
All you have to do is call the parse method with the name of the xml file.
xmlparser.parse(xmlfilename);
If you look at the API documentation that comes with the Xerces parser and search for the parse method you will notice something special.
DOMParser and SAXParser are subclasses of XMLParser.
The parse method throws two exceptions, SAXException and java.io.IOException.
If you try to compile the source code without catching the exception, an error will occur (java.io.IOException must be caught).
Under the previous import statements add the importsfor the IOException and SAXException classes .
import
import org.xml.sax.SAXException;
So now we put a try/catch block around the parse method of DOMParser.
try {
xmlparser.parse(xmlfilename);
} catch (IOException e)
{
System.out.println("Error reading xml file: " e.getMessage());
}
catch (SAXException e)
{
System.out.println("Error in parsing: " e.getMessage());
}
6) Accessing the DOM tree
As DOM creates a tree-based structure based on the xml file,we will need to access the information stored in the tree.
To access the tree call getDocument() and this returns a Document.
Document doc = xmlparser.getDocument();
This Document represents the entire XML document. The data we need to access is stored in nodes. These nodes can have child nodes.
Therefore what you need to do next is walk through the Tree structure (Document) and display the data stored in the Nodes.
Now the Fun starts!!!
7) Walking the nodes
Next we will write a method to display the data in a node. The method will be called displayNode and will take one parameter, the start node.
This method will start from the first node and walk through all the nodes in the XML using recursion.
The nodes in the XML document are of different node types.
The node types can be divided into two broad categories; structural nodes and content nodes.
Structural nodes are not actually part of the content in the document but are used to provide syntax structure.
The following is a list of the different types of nodes:
The main nodes we are interested in are DOCUMENT_NODE, ELEMENT_NODE and ATTRIBUTE_NODE.
Should I use DOM or SAX?
If your document is really large, or you only need to extract a few elements from the whole document, then using DOM is not practical.
SAX Looks for startElement events in which the element name is verse, then looks at each character event for the name SAX is more efficient because we only care about a few elements in the document
SAX is good when:
1)You only need to go through a document once
2)You’re only looking for a few items
3)You’re not too concerned with document structure of the context of the elements you’re looking for
4)You don’t have much memory
DOM Builds Java objects for everything in the document, then walks through the tree looking for the name. Using DOM, we create a lot of Java objects we never use, and we go through the document twice (once to parse it and once to search it)
DOM is good when:
1)You need to go through a document more than once
2)You need to manipulate lots of things
3)in the document The structure of the document and the
4)context of the elements is a concern
5)Memory is not an issue
Java XMLJAVA XML API
The main three main APIs that we shall focus on are:
1.JAXP – Parsing API.
2.JAXM – Messaging API.
3.JAXB – Binding API.
Java API for XML Processing
As a developer, you would program to a special interface. This interface isolates you from specific parsers and coding changes. SAX and DOM are language independent interfaces.
SAX and DOM have two different APIs to access the information from the XML parser. The different APIs use different approaches to access the information in the XML document.
SAX is a low level API and DOM is a high level API. The next sections will cover SAX and DOM in more detail.
XML applications will create a parser object, throw some XML at the parser and then process the results
Simple API for XML (SAX)
SAX is a standard interface for event based XML parsing.
SAX defines a number of events. It’s up to you to listen for them and respond to them.
The documents are accessed serially and an event is triggered at different parts of the document.
The common events are:
1.start of the document
2.start elements
3.characters
4.end elements
5.end of the document.
Basically you would write a program that has event handlers.
SAX is fast and has a low memory requirement.
SAX parsing is harder to setup.
Document Object Model (DOM)
Designed to be a portable interface for manipulating document structures.
Using DOM, the application builds a tree structure of the XML document in memory. The different parts of the XML file are stored in nodes in the DOM document. It then walks back and forth through the nodes in tree.<resource><site><sitename>visualbuilder.com</sitename><emailaddress>webmaster@visualbuilder.com</emailaddress></site>
<site><sitename>activepace.com</sitename><emailaddress>info@activepace.com</emailaddress></site></resource>
Basics of programming using DOM
After you have made sure that your environment has been set up correctly (see Setting up the environment for XML and Java section), you may write your first Java and XML example.
For this example we will use the DOM API discussed in the previous section.
This is a simple example that will read the text “Hello World” from a xml file called “hello.xml”.
1) Import package org.w3c.dom
The Java interfaces have been defined by W3C and are contained in the package org.w3c.dom.
import org.w3c.dom.*;
2) Import Vendor dependent Parser.
The next step is to import a vendor dependent XML parser. In our case it will be the xerces DOM parser that we configured.
import org.apache.xerces.parsers.DOMParser;
Original design by Blogging Secret | Blogger Templates | Ads Theme Blogger Template | maintained by webmaster
