TOMCAT SECURITY AND ANALYSIS
This topic presents an overview of the security features provided with the Apache Jakarta Tomcat servlet container, including suggestions on best practices. Then, an analysis is provided to show how the Cafésoft Access Management System (Cams™) can be integrated with Tomcat to provide enhanced enterprise-wide security that overcomes deficiencies inherent in the servlet and J2EE security model.
Introduction
Tomcat implements security as specified in the Java servlet specification. This document primarily addresses Tomcat 4.x security, which is compliant with the 2.3 servlet specification. Some information is also provided regarding the forthcoming Tomcat 5.x release, which implements the servlet 2.4 specification. Also, there is some overlap between security requirements defined in the servlet and J2EE specifications. In general, the J2EE specification includes all servlet specification requirements and makes some optional requirements mandatory for a web container to be "J2EE compliant". Tomcat implements most optional servlet specification features but, as an open source project, has not been able to pass the J2EE compliance tests due to J2EE licensing policy (recent changes by Sun may allow this in the near future).
Tomcat Security Scope
As stated in the servlet specification, Tomcat security is primarily concerned with:
Authentication - The means by which communicating entities prove their identities to one another.
Access control - The means by which requests for resources are limited to users or programs.
Integrity - The means used to prove that information has not been modified while in transit.
Confidentiality - The means used to ensure that information is understandable only by authorized users.
As defined in the servlet specification, Tomcat security is user role-based and web container (somewhat web application) centric. Hence, Tomcat security scope, by definition in the servlet specification, does not address issues of security integration with other web and application servers.
Declarative and Programmatic Security
The servlet specification classifies Tomcat security into two broad categories:
Declarative security is the expression of application security external to the application and is preferred when sufficient as it allows runtime configuration of application security without recoding the application.
Programmatic security is used to implement fine-grained access control, enabling application components to become security aware.
It may be easier to think in terms of security you configure in the web application environment (declarative) and security you define within the web application code (programmatic). Each web application configures declarative security in its unique deployment descriptor, web.xml. This is a required XML-formatted configuration file (also called the deployment descriptor) found in each web application's WEB-INF directory. Programmatic security involves using HttpServletRequest API method calls to make business logic decisions within the web application context. For example, you may want to make combo box values dynamic based on a user's identity. The servlet API calls you use are:
getRemoteUser - Returns the user name the client used for authentication.
isUserInRole - Determines if a remote user is in a specified security role.
getUserPrincipal - Returns a java.security.Principal object, which contains the principals name and roles.
Tomcat uses role-based authorization to manage access. With this model, access permissions are granted to an abstract entity called a security role, and access is allowed only to users or groups of users who have that role. For example, the Tomcat distribution includes two administrative web applications that only grant access to users with the "manager" role. The deployment descriptor specifies the type of access granted to each role, but does not specify the role to user or group mappings. That's done in the user repository, which is typically a relational database or LDAP server in production environments, but is another XML-formatted file named tomcat-users.xml by default.
Introduction
Tomcat implements security as specified in the Java servlet specification. This document primarily addresses Tomcat 4.x security, which is compliant with the 2.3 servlet specification. Some information is also provided regarding the forthcoming Tomcat 5.x release, which implements the servlet 2.4 specification. Also, there is some overlap between security requirements defined in the servlet and J2EE specifications. In general, the J2EE specification includes all servlet specification requirements and makes some optional requirements mandatory for a web container to be "J2EE compliant". Tomcat implements most optional servlet specification features but, as an open source project, has not been able to pass the J2EE compliance tests due to J2EE licensing policy (recent changes by Sun may allow this in the near future).
Tomcat Security Scope
As stated in the servlet specification, Tomcat security is primarily concerned with:
Authentication - The means by which communicating entities prove their identities to one another.
Access control - The means by which requests for resources are limited to users or programs.
Integrity - The means used to prove that information has not been modified while in transit.
Confidentiality - The means used to ensure that information is understandable only by authorized users.
As defined in the servlet specification, Tomcat security is user role-based and web container (somewhat web application) centric. Hence, Tomcat security scope, by definition in the servlet specification, does not address issues of security integration with other web and application servers.
Declarative and Programmatic Security
The servlet specification classifies Tomcat security into two broad categories:
Declarative security is the expression of application security external to the application and is preferred when sufficient as it allows runtime configuration of application security without recoding the application.
Programmatic security is used to implement fine-grained access control, enabling application components to become security aware.
It may be easier to think in terms of security you configure in the web application environment (declarative) and security you define within the web application code (programmatic). Each web application configures declarative security in its unique deployment descriptor, web.xml. This is a required XML-formatted configuration file (also called the deployment descriptor) found in each web application's WEB-INF directory. Programmatic security involves using HttpServletRequest API method calls to make business logic decisions within the web application context. For example, you may want to make combo box values dynamic based on a user's identity. The servlet API calls you use are:
getRemoteUser - Returns the user name the client used for authentication.
isUserInRole - Determines if a remote user is in a specified security role.
getUserPrincipal - Returns a java.security.Principal object, which contains the principals name and roles.
Tomcat uses role-based authorization to manage access. With this model, access permissions are granted to an abstract entity called a security role, and access is allowed only to users or groups of users who have that role. For example, the Tomcat distribution includes two administrative web applications that only grant access to users with the "manager" role. The deployment descriptor specifies the type of access granted to each role, but does not specify the role to user or group mappings. That's done in the user repository, which is typically a relational database or LDAP server in production environments, but is another XML-formatted file named tomcat-users.xml by default.
Figure 1 - Security snippet from Tomcat Manager's web.xml deployment descriptor
Figure 1.0 shows a security snippet from the Tomcat Manager web application's web.xml file. The security contraint element defines the URL pattern to match for the constraint to apply (in this example the entire web application) and an authentication constraint, which will force the user to authenticate. Access is granted only if an authenticated user has the "manager" role. The login config element defines the type of authentication (more on this next), in this case HTTP basic. And, the roles referenced by the web application.
Figure 1.0 shows a security snippet from the Tomcat Manager web application's web.xml file. The security contraint element defines the URL pattern to match for the constraint to apply (in this example the entire web application) and an authentication constraint, which will force the user to authenticate. Access is granted only if an authenticated user has the "manager" role. The login config element defines the type of authentication (more on this next), in this case HTTP basic. And, the roles referenced by the web application.
0 comments
Post a Comment