Set up, enabling and migrating security

We must address several issues prior to authenticating users, authorizing access to resources, securing applications, and securing communications. These security issues include migration, interoperability, and installation.

After installing WebSphere Application Server, we can determine the proper level of security needed for your environment. By default, administrative security is enabled and provides the authentication of users using the WebSphere administration functions, the use of SSL, and the choice of user account repository.

We can also use the following permissions to enhance security:

• Use the getSSLConfig permission to give the application code the ability to call several of the JSSEHelper methods. For more information about these methods, see the description of the com.ibm.websphere.ssl.JSSEHelper API in the Programming interfaces section of the Information Center.

• Use the AdminPermission permission to give the application code the ability to call WebSphere Application Server administrative APIs. See the topic Setting Java 2 security permissions for an example of how to set this permission.

• Use the accessRuntimeClasses permission to give the application code the ability to load classes that are included with the product. If we are operating in an environment that normally restricts access to these classes, this permission enables the application code to bypass this restriction during class loading. See the topic Global security settings for a description of how to set this permission.

The following information is covered in this section:

• (dist)(zos) Determine if any migration and interoperability issues might affect the installation. For more information, see Migrate, coexist, and interoperate - Security considerations.

• (dist)(zos) Prepare the environment before and after installing WebSphere Application Server. For more information, see Preparing for security at installation time.

• Enable security for all the application servers or for specific application servers in the realm.

  For more information, see either Enable security or Configure multiple security domains.

What to do next

After installing WebSphere Application Server and securing the environment, you must authenticate users. For more information, see Authenticating users.

Subtopics

• Migrate, coexist, and interoperate - Security considerations
  Use this topic to migrate the security configuration of previous WebSphere Application Server releases and its applications to the new installation of WAS.

• (dist)(zos) Prepare for security at installation time
  Complete the following tasks to implement security before, during, and after installing WebSphere Application Server.

• (zos) Enable administrative security and the default application security policy
  Use this panel to configure administration and the default application security policy. This security configuration applies to the security policy for all administrative functions and is used as a default security policy for user applications. Security domains can be defined to override and customize the security policies for user applications.

• Enable security
  The following provides information on how to configure security when security was not enabled during the WebSphere Application Sever profile creation.

• Secure specific application servers
  We can customize security to some extent at the application server level. We can disable administrative security on an application server.

• (zos) Controlling access to console users when using a Local OS Registry
  Adding console users and authorizing them for a cell involves adjusting the user registry and authorization settings. A user registry custom property governs the form of authorization of console users. Regardless of the form of authorization used, the outcome is that an MVS™ user ID for the WebSphere administrator identity is able to access all administrative console functions and use the administrative scripting tool when security is first enabled.

• (zos) Use CBIND to control access to clusters
  Use the CBIND class in RACF to restrict a client's ability to access clusters from Java Application Clients or J2EE compliant servers. We must have READ permission to access clusters.

Related concepts

Multiple security domains

Related tasks

Authenticating users

Configure multiple security domains

Set Java 2 security permissions

Global security settings