Secure > Enable WebSphere Application Server security


Enable WebSphere global security

Global security represents the security configuration that is effective for the entire security domain. It includes the configuration of...

J2EE role-based authorization guards access to Web resources such as servlets, JSPs files, and EJB methods.

Enabling application security prevents all EJB components from being exposed to remote invocation by anyone. If you operate the WebSphere Commerce site from behind a firewall, you can disable application security. However, you should disable it only if you are sure that no malicious applications are running behind the firewall.

The WCS instance has global security enabled by default during the instance creation process. That is, WAS administrative security is enabled, with application security disabled by default. Disabling application security has the advantage of better performance when compared to running with application security enabled. The primary administrative user is a user from the built-in file registry. The instance creation process creates the user by initially taking the credentials used to login to the WCS Configuration Manager. You can change the primary administrative user using the WAS Administrative Console.

Global security controls both administrative security and application security.

Due to the fact that WCS has its own authentication and authorization structure, you may disable application security if WCS is deployed in a trusted zone behind a firewall.

This configuration will allow you to enable the single sign-on capability and secure WAS administrative functions without exercising any J2EE security checks on the application.


Before you begin

  1. When enabling WebSphere global security, it is strongly recommended that the machine meets the following requirements:

    • A minimum machine memory of 1 GB.
    • A minimum heap size of 384 MB, for the WCS application.

  2. When enabling WebSphere global security on Windows 2003 platform, it is recommended that you enlarge the TCP Ports to 65534 on all nodes on the system that are running on Windows 2003. This includes the WCS node, the LDAP server node, and the Commerce-enabled Portals node.

    After enlarging the TCP Ports, we will need to restart the servers on the nodes that were changed.

    See: When you try to connect from TCP ports greater than 5000 you receive the error 'WSAENOBUFS (10055)'

    If you do not enlarge the TCP Ports, you might receive an error similar to the following:

    Authentication failed for user uid=wpsbind,cn=users,dc=ibm,dc=com because of the following exception javax.naming.CommunicationException: svt4.cn.ibm.com:389.
    Root exception is java.net.BindException: Address in use: connect

  3. After WebSphere global security is enabled for a WCS instance or payment instance, provide a username and password when starting and stopping the WCS instance or payment instance. For example:

    stopServer.sh server1 -username administrator -password password

Before you begin to enable security, we will need to know how the WebSphere Application Server, where you are enabling security, validates user IDs. WAS can use the operating system user registry or federated repositories as the WAS user registry.

See one of the following pages for instructions on enabling security using one of the user registries:

The application server where WebSphere Commerce and WebSphere Commerce Payments are deployed is configured to use the DummyServerKeyFile.jks and DummyServerTrustFile.jks files with the default self-signed certificate out-of-the-box. Using the dummy key and trust file certificates is not safe; consequently, you should generate the own certificate to replace the dummy certificates immediately.

For information about encoding passwords in files see Encoding password in files.


Procedure


See also


+

Search Tips   |   Advanced Search