InfoCenter Home >
5: Securing applications -- special topics >
5.3: Changes to security since Version 3

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.
Go to previous article: Operating environment Go to next article: Overview: Using Using programmatic and form logins

 

 
Go to previous article: Operating environment Go to next article: Overview: Using Using programmatic and form logins