Authentication using HTTPS (HTTP over SSL) enables browsers and web servers to communicate over an encrypted connection. This is a two-way process, meaning that both the server and the browser encrypt all traffic before sending out data. Tomcat uses HTTPS for confidentiality (by encrypting the data) and integrity (which is insured if the message can be decrypted).
Another important aspect of the SSL protocol is authentication. This means that during your initial attempt to communicate with a web server over a secure connection, that server will present your web browser with a set of credentials, in the form of a certificate chain, as proof the site is who and what it claims to be. Though Tomcat supports HTTPS connections and server authentication, it is generally recommended that you off-load SSL connections to a web server like Apache or IIS and use Tomcat as a plugin to process the servlet and JSP requests.
The server may also request a client certificate from your browser, asking for proof that you are who you claim to be. This practice is used more for business-to-business transactions than with individual internet users because of the overhead required to manage certificates. Most SSL-enabled web servers do not request client authentication but if you need it, Tomcat does support it.
Web Application Single Sign-on
As the underlying principals to which roles are mapped are environment specific rather than web application specific, it is desirable to:
- Make login mechanisms and policies a property of the web application environment.
- Use the same authentication information to represent a principal to all applications in the same container, and
- Require re-authentication of users only when a security policy domain boundary has been crossed.
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:
- You have a web server farm with more than one stand-alone Tomcat server
- You are using Apache and Tomcat servers and desire integrated security
- You need centralized security configuration, logging, and events
- You need a flexible, easy-to-extend security system
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.
0 comments
Post a Comment