Secure a Web application, Java-style - JavaWorld April
2000
Tutorial Details:
Secure a Web application, Java-style
Secure a Web application, Java-style
By: By Michael Cymerman
Use Java's multiple-layer security implementation to protect your Web
eb security can be defined in various ways, depending on individual points of view. The main focus of security in this article is the safety of applications developed and deployed for the Internet. Here, I will outline some software security measures that you can take to secure your application. While none of them is completely infallible, combining these approaches with hardware can help prevent malicious attacks on your business.
The two main concepts of security are authentication and authorization. I will describe each of them in the following sections and provide examples of how you can implement them in your applications. In addition, I will discuss some key classes of the Java Security API to prepare for a more detailed example that combines form-based authentication with Java's security model. The concepts outlined in the example should enable your enterprise to produce a security policy for your Java-based applications.
Authentication
Authentication is the process by which users' access privileges are verified prior to their entering a Website's protected area. There are two major authentication approaches: basic authentication and form-based authentication.
Basic authentication
Basic authentication relies on the Web server for authentication to protected areas. Sites protected by basic authentication let the user browse through unprotected areas without requiring the user to enter a password. However, the browser will automatically prompt the user for a password and username should he or she attempt to access a secure page. This prompt comes in the form of a dialog box.
The username and password combination is then encoded (base 64) and passed in an unencrypted form to the Web server. The Web server compares the encoded value against values stored in a flat file, a database, or a directory server.
If the user is authenticated, the server then verifies that the user has the privilege to access the requested page against a file, such as httpd.conf. If the user has access, the Web server then serves the page. If the user is denied access, the server either requests the username/password combination again or presents an error message on the browser window.
Because the actual syntax of the basic authentication varies between servers, I do not present any here. There are numerous Web resources describing the syntax of the various servers.
Form-based authentication
The majority of sites use an approach called form-based lazy authentication, which lets users navigate through unprotected areas of the site without requiring a password. Only when the user wants to access protected areas, such as ordering or account status, does the site present a login form. This is the most common security approach and is used by large e-commerce firms, such as Barnes & Noble. The benefit of this approach is that users are not subjected to the wait times associated with authentication unless they truly need access to a protected page.
As the most common security scheme on the Web, form-based lazy authentication lends itself to the example presented in this article.
Use forms to authenticate clients
A common way for servlet-based systems to perform authentication is to use the session to store information indicating that a user has logged into the system. In this scheme, the authentication logic uses the HttpSession object maintained by the servlet engine in the Web server.
A base servlet with knowledge of authentication is helpful in this case. Using the service method of the BaseServlet , the extending servlets can reuse the security check functionality. All code used in this example can be found in Resources .
The service method is shown in the following code snippet:
public void service(HttpServletRequest request, HttpServletResponse
response)
throws IOException, ServletException
{
// check to see if a session has already been created for this user
// don't create a new session yet.
HttpSession session = request.getSession( false);
String requestedPage = request.getParameter(Constants.REQUEST);
if ( session != null)
{
// retrieve authentication parameter from the session
Boolean isAuthenticated = (Boolean)
session.getValue(Constants.AUTHENTICATION);
// if the user is not authenticated
if ( !isAuthenticated.booleanValue() )
{
// process the unauthenticated request
unauthenticatedUser(response, requestedPage);
}
}
else // the session does not exist
{
// therefore the user is not authenticated
// process the unauthenticated request
unauthenticatedUser(response, requestedPage);
}
}
Notice that you can expand this method to perform other generic functions as well. In this example, I developed only the security aspects of this class.
The BaseServlet attempts to retrieve the session from the servlet engine. On retrieval, the servlet verifies that the user has been granted access to the system. Should either of these checks fail, the servlet redirects the browser to the login screen.
On the login screen, the user is prompted for a username and password. Note that the data passed from the browser to the Web server is unencrypted unless you use Secure Socket Layer (SSL).
The LoginServlet uses the username/password combination to query the database to ensure that this user does indeed have access to the system. If the check fails to return a record for that user, the login screen is redisplayed. If the check is successful, the following code stores the user authentication information inside a session variable.
// create a session
session = request.getSession( true);
// convert the boolean to a Boolean
Boolean booleanIsAuthenticated = new Boolean( isAuthenticated);
// store the boolean value to the session
session.putValue(
Constants.AUTHENTICATION,
booleanIsAuthenticated);
In this example, it's assumed that any user who successfully authenticates to the system has access to the pages displayed prior to login. However, there are cases in which the application development team may require a more refined security approach to satisfy its requirements.
Authorization
Authorization verifies that the security policies protect against more sophisticated hackers by preventing unauthorized code from connecting to back-office systems, such as Enterprise JavaBeans (EJB). There are two types of authorization: code authorization and caller authorization.
Code authorization
Your security team can prevent unauthorized code use by limiting the classes available to the virtual machine used by the servlet engine. You can achieve this process of code authorization by removing unnecessary entries from the classpath.
The security team has complete control over which code should be included in the classpath and can therefore authorize the code prior to inclusion. The team should ensure that the code does not have access to third-party tools or extraneous code.
Caller authorization
In addition to code authorization, you can also authenticate the caller of back-office systems. The EJB model, for example, lets the development team specify a username and password for access to any bean deployed in a container.
Any code that attempts to connect to these beans must pass the username/password combination to the container for authorization. A failed authorization results in an exception that prevents the caller from completing its action.
Authorization example
In this second example, I'll explore the mechanisms built into the EJB specification for preventing unauthorized access to the business logic. While this example is based on the WebLogic Tengah server, the concepts hold true for other servers even though the syntax will differ. See Resources for the code or configuration files used in this example.
In the EJB's deployment descriptor, the following code identifies the access control entries associated with the bean:
(accessControlEntries
DEFAULT [administrators basicUsers]
theRestrictedMethod [administrators]
); end accessControlEntries
Notice that two user categories have been identified. Administrators have access to the bean by default and constitute the only user group that has access to theRestrictedMethod .
Once you've authorized that the administrators have access to the bean, you now need to create properties detailing which users are in the administrators group. To do this, the weblogic.properties file must include the following lines:
weblogic.password.JoeAdministrator=joe
weblogic.security.group.administrators=JoeAdministrator
weblogic.password.JaneBasic=jane
weblogic.security.group.basicUsers=JaneBasic
At this point, you've established the users who have access to the bean and have restricted certain specific methods. This helps limit the potential for malicious attacks on your Web server to reach the business logic stored in the beans.
The last step in this EJB authorization example is to establish the client connection to the bean. In this case, the client must specify the username/password combination properly in order to have access to the restricted bean or methods. An example client communication follows:
try{
Properties myProperties = new Properties();
myProperties.put( Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.T3InitialContextFactory");
myProperties.put(Context.PROVIDER_URL, "t3://localhost:7001");
myProperties.put(Context.SECURITY_PRINCIPAL, "JoeAdministrator");
myProperties .put(Context.SECURITY_CREDENTIALS, "joe");
ic = new InitialContext(myProperties);
...
}
catch (Exception e) { ... }
Since you've passed the JoeAdministrator user to the InitialContext , you'll have access to any method to which the administrators group has been granted access. If your application makes connections to external beans or your beans are used by external applications, you should implement this
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Secure a Web application, Java-style - JavaWorld April
2000
View Tutorial: Secure a Web application, Java-style - JavaWorld April
2000
Related
Tutorials:
 Integrate security infrastructures with JBossSX
Integrate security infrastructures with JBossSX
|
Mix protocols
transparently in
Web applications
Mix protocols
transparently in
Web applications
|
Jtrix: Web
services beyond SOAP
Jtrix: Web
services beyond SOAP
|
Create your own type 3 JDBC driver, Part 2
Create your own type 3 JDBC driver, Part 2
|
Yes, you can secure your Web services documents, Part 1
Yes, you can secure your Web services documents, Part 1
|
Yes, you can secure your Web services documents, Part 2
Yes, you can secure your Web services documents, Part 2
|
Update distributed applications
Update distributed applications
|
Secure Web
services
Secure Web
services
|
jGuard v0.60 released!
jGuard v0.60 released!
i am pleased to announce a new major release(v0.60) of the java security library called jGuard(http://sourceforge.net/projects/jguard/).
this library is build on top of jaas, for J2EE web applications.
his goal is to provide f
|
Java Servlets: Design Issues
This article covers the principal concepts associated with servlets. This article examines some of the design issues, and offers some guidelines on the applicability of Java servlets for web based application development.
|
Networking our whiteboard with servlets.
Find out how to easily replace the RMI and sockets networking layers with servlets.
|
JavaTM Secure Socket Extension (JSSE)
The JavaTM Secure Socket Extension (JSSE) is a Java package that enables secure Internet communications. It implements a Java version of SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols and includes functionality for data encryption
|
Sun Researchers Unveil World's Smallest Secure Web Server
The Next Generation Crypto team at Sun Microsystems Laboratories has created this small secure web server, nicknamed Sizzle (from SSSL for "Slim SSL"). The coin-sized server is designed to be embedded in a wide array of tiny devices for secure monitorin
|
Struts, JavaServer Faces, and Java Studio Creator:
The Evolution of Web Application Frameworks Sun Microsystems' Craig McClanahan, the creator of the Apache Struts Framework, co-specification lead for JavaServer Faces 1.0, and prime architect for Sun Java Studio Creator's new release, explains all three.
|
Developing Distributed application using Enterprise Java Beans, J2EE Architecture, EJB Tutorial, WebLogic Tutorial.
Developing Distributed application using Enterprise Java Beans, J2EE Architecture, EJB Tutorial, WebLogic Tutorial.
Distributed Architecture
Two-tier application:
In the past two-tier applications were used. Two-tier applications are also know as
|
Buy SuSe 9.1 Personal CDs in India from us. Suse 9.1 Personal is available with us.
Buy SuSe 9.1 Personal CDs in India from us. Suse 9.1 Personal is available with us.
SuSe 9.1 Personal Linux
Now Available SuSe 9.1 Personal CD's
SuSE 9.1 Personal Edition was based on the x86 port of the Personal Edition, and it includes all of
|
Accessing Database from servlets through JDBC!
Accessing Database from servlets through JDBC!
Java Servlets
J ava Servlets are server side components that provides a powerful mechanism for developing server side of web application. Earlier CGI was developed to provide server side capabilities
|
WAP Toolkits Motorola - Mobile ADK 1.1 Nokia - WAP Toolkit
WAP Toolkits Motorola - Mobile ADK 1.1 Nokia - WAP Toolkit
Tutorial
WAP Toolkits
T o develop any WAP application you have to download software essential for development. Although you can write and test your codes through our site for learning
|
What is Web Hosting
What is Web Hosting
What is Web Hosting?
What is Web Hosting?
If you have a company and want web presence than you need a website. With the website any one from the world must be able to view your pages, images etc.
Website is actually a
|
Pure Java SSH Tool for J2ME
JSch is the pure Java SSH2 implementation developed by JCraft under revised BSD license. It has been already widely adopted by several open source projects, including Eclipse, Apache Ant, etc.,
|
|
|
|
