InfoCenter Home >
5: Securing applications -- special topics >
5.3: Changes to security since Version 3
With version 4.0, WebSphere Application Server adopts the security model described in
the Java 2 Enterprise Edition (J2EE) specification. This specification describes
techniques for creating, assembling, deploying, and securing enterprise applications. The
security-related aspects of J2EE are now supported by WebSphere and include the following:
- The use of J2EE deployment descriptors to declaratively specify various security
constraints for Web and enterprise-bean resources. This change is important because many
of an application's security attributes are now specified during the creation and assembly
phases instead of during the deployment phase. In Version 3.x, most application-level
security attributes are specified during the deployment phase.
- The use of role-based authorization.
Many security features have changed with respect to the security offered by IBM
WebSphere Application Server Version 3. This table summarizes the differences.
Version 4 |
Version 3.x |
When global security is enabled, only the resources of the administrative
application are protected. All other resources are unprotected. |
When global security is enabled, enterprise beans are protected by
default. |
WebSphere no longer secures or protects URIs, for example, HTML files and
CGI scripts, that are served by an external Web server, for example, Apache or IHS.
WebSphere secures or protects only URIs served by WebSphere. URIs not served by WebSphere
can be protected with IBM's WebSeal security solution, or the URIs and the resources they
represent can be restructured and packaged in a Web application archive (a WAR file) so
that WebSphere can serve them. |
WebSphere can protect URIs served by an external Web server. |
Deployment descriptors are provided in XML. The web.xml, ejb-jar.xml, and
application.xml deployment-descriptor files are used to declare security contraints.
Security constraints include the identification of the methods belonging to roles, the
login configuration or challenge mechanism, whether HTTPS/SSL is required, and so forth.
The application assembly tool (AAT) is used to create and manipulate deployment
descriptors and the various archive (EAR, WAR, and JAR) files that contain them. |
Most of application-specific security attributes are defined by using the
administrative console during the application's deployment phase. |
The login configuration and challenge type apply to individual Web
applications, not to individual enterprise applications. |
The challenge type applies to an entire enterprise application. |
The local operating-system user registry now supports J2EE form-based
login configuration. This means that AEs can now supports the form-based login
configuration. J2EE form-based login replaces AbstractLoginServlet, CustomLoginServlet,
and SSOAuthenticator, which are now deprecated. Although these features still exist in
version 4.0, they are intended to be used for migration purposes only until the
application can be modified to use J2EE form-based login. |
AbstractLoginServlet, CustomLoginServlet, and SSOAuthenticator are
features used to create custom or form based login mechanisms for web applications.
CustomLogin servlets are supported only with the LTPA authentication mechanism, which is
available only in Advanced Edition. |
Passwords are encoded with a simple masking alogorithm in various ASCII
WebSphere configuration files to deter casual observation. |
Passwords are in plain text. |
|
|