Migrate security configurations from previous releases
Many of the Version 4.0 security functions are still supported in Version 5, but these functions are deprecated and may be removed in a future release. While you may still run your Version 4 applications, it is recommended that you migrate to the Version 5 security functions.
This topic describes how to migrate from these deprecated security functions. It does not describe how to migrate your entire Version 4 configuration to Version 5. For more information about migrating your Version 4 configuration, see Migration for migration instructions and tools.
Here are some migration points that you need to consider:
For security-enabled Java thin clients, programmatically setting security providers in the main() method is no longer required. For more information see Run your thin or pluggable application client with security enabled in the Application development topic.
To comply with the Servlet 2.3 specification, authorization to Web resources is no longer enforced through declarative security when the Web resources are requested by a servlet or JSP through the forward() or include() methods of the javax.servlet.RequestDispatcher class. If this change impacts your Web applications, consider protecting the originally requested servlet using J2EE role based security. If the servlet is already protected, you may also need to implement programmatic security in the servlet to protect the Web resources that are invoked through a forward() or include() method. For more information, see Develop secure Web applications.
See these additional topics for information about migrating your Version 4.0 secured applications to Version 5.0:
Migrate applications to use Java keystores
If your WebSphere Application Server applications use OS/400 *SYSTEM certificate stores (.kbd files), see this topic for information about using Java keystores (.jks files). WebSphere Application Server for iSeries Version 5 does not fully support the use of OS/400 *SYSTEM certificate stores with Java applications.Migrate custom user registries
If you developed Version 4 custom user registries, see this topic for information about migrating to the Version 5 implementation.Migrate CORBA programmatic login to JAAS
If you developed a CORBA programmatic login in Version 4, see this topic for information about migrating to the recommended Java Authentication and Authorization Service (JAAS) implementation.Migrate from CustomLoginServlet to form-based login and servlet filters
If your Version 4 application uses the CustomLoginServlet to perform authentication, see this topic for information about using form-based login and servlet filters instead.Migrate Java 2 Security policy
Enterprise application that run on Version 4.x with Java 2 Security enabled are not guaranteed to run seccessfully when migrating to Version 5 with Java 2 Security enabled. This is because the default Java 2 Security policy for enterprise application is more more stringent and all permissions are enforced. Furthermore, while Java 2 Security is optional, it is enabled by default when you enable WebSphere global security. If Java 2 Security is enabled, all of your WebSphere applications must be fully enabled for Java 2 Security.Migrate Java thin clients that use the OS400 password encoding algorithm
The os400.security.password.validation.list.object property is now instance dependent. See this topic for instructions on migrating your client configuration.Migrate trust association interceptors
If you developed a WebSeal or custom trust association interceptor for the Version 4 product, see this topic for changes to the implementation.