Administrative security
Administrative security inclues whether security is used at all, the type of registry used for against for authentication. Plan carefully: Incorrectly enabling administrative security can lock one out of the administrative console or cause the server to end abnormally. IBM recommends allowing the default installation to install administrative security as turned on by default.
Administrative security activates a wide variety of security settings, including the authentication of users, the use of SSL, and the choice of user account repository. In particular, application security, including authentication and role-based authorization, is not enforced unless administrative security is active. Administrative security is enabled by default.
Administrative security need not be activated in order for WebSphere applications to make use of JSSE methods to encrypt communication to remote sites.
Administrative security represents the security configuration effective for the entire security domain. A security domain consists of all of the servers configured with the same user registry realm name. The realm can be the machine name of a local operating system registry. In this case, all of the application servers must reside on the same physical machine. In other cases, the realm can be the machine name of a stand-alone LDAP registry.
A multiple node configuration is supported because we can access remotely user registries that support the LDAP protocol. Therefore, we can enable authentication from anywhere.
Access ID
The basic requirement for a security domain is that the access ID returned by the registry or repository from one server within the security domain is the same access ID as that returned from the registry or repository on any other server within the same security domain. The access ID is the unique identification of a user and is used during authorization to determine if access is permitted to the resource.
The administrative security configuration applies to every server within the security domain.
Turning on administrative security activates the settings that protect the server from unauthorized users. Administrative security is enabled by default during the profile creation time. There might be some environments where no security is needed such as a development system. On these systems we can elect to disable administrative security. However, in most environments we should keep unauthorized users from accessing the administrative console and the business applications. Administrative security must be enabled to restrict access.
What does administrative security protect?
The configuration of administrative security for a security domain involves configuring the following technologies:
- Authentication of HTTP clients
- Authentication of IIOP clients
- Administrative console security
- Naming security
- Use of SSL transports
- Role-based authorization checks of servlets, enterprise beans, and mbeans
- Propagation of identities (RunAs)
- CBIND checks
- The common user registry
- The authentication mechanism
- Other security information that defines the behavior of a security domain includes:
- The RMI/IIOP authentication protocol
- Other miscellaneous attributes
IBM recommends that before registering a node with an administrative agent process, first have administrative security enabled in the administrative agent and base profile. After a profile is registered with the administrative agent, the state of administrative security enablement cannot be changed.
Subtopics
Enable security Security considerations when adding a base Application Server node to WebSphere ND