Previous | Home | Next


Secure the dmgr console

Administrative security...

Enabling administrative security does not enable application security.

If we enable security when we create a profile for distributed systems, a file-based registry is automatically created and populated with one administrative user ID. We can federate additional registries to the existing file-based registry to manage users and groups for application security.

For registries other than the WAS federated user registry, create at least one user ID to be used for the WebSphere administrator.

Security domains are used for application security, not administrative security.


Enable security after profile creation

We can enable administrative security after profile creation through the dmgr console by navigating to...

Complete the configuration items for authentication, authorization, and realm (user registry). Populate the chosen user registry with at least one user ID to be used as an administrator ID.

We can use the Security Configuration Wizard in the Security settings page that assists you in securing the environment. To do this, click the Security Configuration Wizard button. Click Next through the various windows of the wizard.

  1. Select whether to enable application security or if you need to use Java2 security to restrict application access to local resources.

    When you select to enable administrative security, the application security check box is enabled automatically.

    If you are not prepared to use application security at this time, be sure to clear the box. Java 2 security can be selected at this point or any time after enabling the administrative security.

  2. Select the type of user registry that you need for the environment:

    Federated repositories Manage identities stored in multiple repositories in a single, virtual realm.
    Standalone LDAP Server Use the LDAP user registry settings. Select in case the users and groups reside in an external LDAP registry
    Local operating system Use the local operating system user registry of the application server.
    Standalone custom registry Custom registry that implements the UserRegistry interface in the package...

      com.ibm.websphere.security package.

  3. Select the primary administrative user name and other options depending on the previous optioned selected.

    We use federated repositories, which requires the password for the primary administrative user to be specified and confirmed.


Security settings page

Restart your deployment manager server process to be able to login to the administrative console using the user name and password selected.

In larger environments, we can use an LDAP server for the user repository...

To add a connection to an LDAP server, after you enabled the administrative security and set the user repository to federated repositories:

  1. In the Java2 security section of the security settings window, click Configure.

  2. In the Federated repositories window, click Add repositories (LDAP, custom, etc).

  3. In the Repository reference window, click New Repository.

  4. Select LDAP Repository from the drop-down list.

  5. Add all of the necessary information in the General Properties window according to your LDAP environment.

  6. Click Apply and then click Save.

If you enable administrative security, and then find that we cannot log in, we can disable security through scripting or manually editing the security.xml profile. This action allows you to go back through the security configuration to see what is causing the problem.

To disable administrative security through scripting:

  1. cd dmgr_PROFILE_HOME/bin directory.

  2. Start the wsadmin scripting client with the -conntype none argument.

  3. Enter the securityoff command in JACL mode or securityoff () command in Jython mode.

  4. Exit the wsadmin scripting client.

  5. Restart your processes.

    When starting the wsadmin scripting client with the -conntype none argument, the securityoff command toggles the...

      enabled="true"

    ...in security.xml to...

      enabled="false"

    The wsadmin session is in local mode and in this case acts as a text editor to make the needed configuration change.

To manually edit the security.xml file:

  1. Open the security.xml file at dmgr_PROFILE_HOME/config/cells/cellname.

  2. Edit the second line, changing enabled="true" to enabled"false" 
    <security:Security xmi:version="2.0" 
                   xmlns:xmi="http://www.omg.org/XMI"
                   xmlns:orb.securityprotocol="http://www.ibm.com/websphere/appserver/schemas/5.0/orb.securityprotocol.xmi"
                   xmlns:security="http://www.ibm.com/websphere/appserver/schemas/5.0/security.xmi" 
                   xmi:id="Security_1" 
                   useLocalSecurityServer="true"
                   useDomainQualifiedUserNames="false" 
                   enabled="false" 
                   cacheTimeout="600"
                   issuePermissionWarning="true" 
                   activeProtocol="BOTH"
                   enforceJava2Security="false" 
                   enforceFineGrainedJCASecurity="false"
                   appEnabled="true" 
                   dynamicallyUpdateSSLConfig="true" 
                   allowBasicAuth="true"
                   activeAuthMechanism="LTPA_1" 
                   activeUserRegistry="WIMUserRegistry_1"
                   defaultSSLSettings="SSLConfig_1">

    If administrative security is enabled, each time you log in to the dmgr console, authenticate with the user ID that was identified as having an administrative role. Entering commands from a command window also prompts you for a user ID and password.

    We can add additional administrative users and assign authorization levels from the dmgr console.


Administrative security roles

Administrative security is based on identifying users or groups that are defined in the active user registry and assigning roles to each of those users. When you log into the dmgr console or issue administrative commands, use a valid administrator user ID and password. The role of the user ID determines the administrative actions the user can perform.


Authorization groups

Prior to WAS V6.1, users granted administrative roles and administered all of the resource instances under the cell. Starting with v6.1, administrative roles are now per resource instance rather than to the entire cell. Resources that require the same privileges are placed in a group called the authorization group. Users can be granted access to the authorization group by assigning to them the required administrative role within the group.

A cell-wide authorization group exists for backward compatibility. Users who are assigned to administrative roles in the cell-wide authorization group can still access all of the resources within the cell.

The following administrative security roles are available:

Administrator Operator permissions, configurator permissions, and the permission required to access sensitive data, including server password, LTPA password and keys, and so on.
Auditor View and change the configuration settings for the security auditing subsystem.
Configurator Monitor permissions. Can change the WAS configuration.
Operator Monitor permissions. Can change the runtime state, for example, start or stop services.
Monitor View the WAS configuration and current state.
Deployer Perform configuration actions and runtime operations on applications.
Admin Security Manager Map users to administrative roles. Manage authorization groups. Cannot map users to administrative roles.
ISC Admin Administrator privileges for managing users and groups within the dmgr console only.


Assigning administrative roles to users and groups

If we are using a file-based repository, we can add users and groups through the console by clicking Users and Groups | Manage Users or Users and Groups | Manage Groups. Otherwise, the users and groups must be added to the user registry using the tools provided by the registry product.

Role assignments for users and groups are managed through the dmgr console.

Use these windows to assign an administrative role to a user or group.


Fine-grained security

WAS administrative security is fine-grained, meaning that access can be granted to each user per resource instance. For example, users can be granted configurator access to a specific instance of a resource (an application, an application server, or a node). The administrative roles are assigned per resource instance rather than to the entire cell.

To achieve the instance-based security or fine-grained security, resources that require the same privileges are placed in a group called the administrative authorization group or authorization group. Users can be granted access to the authorization group by assigning to them the required administrative role.

We can define groups of resources that are treated collectively by clicking Security | Administrative Authorization Groups. The resource instances that are added to an authorization group can be the following types:

After the authorization group is created, we can assign users or groups an administrative role for the authorization group.

Many dmgr console pages have a preference setting that allows you to restrict the items that we can see to those that are valid for the authorization group level. The roles that we can choose from depend on the role of the user ID that logged into the dmgr console.

Consult: WAS V8 Security Guide, SG24-7971