Secure administration, applications, and infrastructure settings

Security has some performance impacts on your applications. The performance impacts can vary depending upon the application workload characteristics. You manage the effect of security on you workload by configuring administrative, application, and infrastructure security on a global level.

To view this administrative console page, click Security > Secure administration, applications, and infrastructure.

When security is configured, validate any changes to the user registry or authentication mechanism panels. Click Apply to validate the user registry settings. An attempt is made to authenticate the server ID or to validate the admin ID (if internalServerID is used) to the configured user registry. Validating the user registry settings after enabling administrative security can avoid problems when you restart the server for the first time.

Configuration tab

Security configuration wizard

Launches a wizard that enables you to configure the basic administrative and application security settings. This process restricts administrative tasks and applications to authorized users.

Using this wizard, you can configure application security, resource or Java 2 Connector (J2C) security, and a user registry. You can configure an existing registry and enable administrative, application, and resource security.

When you apply changes made by using the security configuration wizard, administrative security is turned on by default.

Security configuration report

Launches a security configuration report that displays the core security settings of the application server. The report also displays the administrative users and groups and the CORBA naming roles.

A current limitation to the report is that it does not display application level security information. The report also does not display information on Java Message Service (JMS) security, bus security, or Web Services security.

Enable administrative security

Specifies whether to enable administrative security for this application server domain. Administrative security requires users to authenticate before obtaining administrative control of the application server.

For more information, see the related link for administrative roles.

When enabling security, set the authentication mechanism configuration and specify a valid user ID and password (or a valid admin ID when internalServerID feature is used) in the selected registry configuration.

Note: There is a difference between the user ID (which is normally called the admin ID), which identifies administrators who manage the environment, and a server ID, which is used for server-to-server communication. You do not need to enter a server ID and password when you are using the internal server ID feature. However, optionally, you can specify a server ID and password. To specify the server ID and password, complete the following steps:
  1. Click Security > Secure administration, applications, and infrastructure.
  2. Under User accounts repository, select the repository and click Configure.

You can specify either the Automatically generated server identity option or the User identity for the z/OS started task option.

If you have problems, such as the server not starting after enabling security within the security domain, resynchronize all of the files from the cell to this node. To resynchronize files, run the following command from the node: syncNode -username your_userid -password your_password. This command connects to the deployment manager and resynchronizes all of the files.

If your server does not restart after you enable administrative security, you can disable security. Go to your app_server_root/bin directory and run the wsadmin -conntype NONE command. At the wsadmin> prompt, enter securityoff and then type exit to return to a command prompt. Restart the server with security disabled to check any incorrect settings through the administrative console.

Local OS user registry users: When you select Local OS as the active user registry, you do not need to supply a password in the user registry configuration.

Default: Enabled

Enable application security

Enables security for the applications in your environment. This type of security provides application isolation and requirements for authenticating application users

In previous releases of WebSphere Application Server, when a user enabled global security, both administrative and application security were enabled. In WebSphere Application Server Version 6.1, the previous notion of global security is split into administrative security and application security, each of which you can enable separately.

As a result of this split, WebSphere Application Server clients must know whether application security is disabled at the target server. Administrative security is enabled, by default. Application security is disabled, by default. To enable application security, you must enable administrative security. Application security is in effect only when administrative security is enabled.

Default: Disabled

Use Java 2 security to restrict application access to local resources

Specifies whether to enable or disable Java 2 security permission checking. By default, access to local resources is not restricted. You can choose to disable Java 2 security, even when application security is enabled.

When the Use Java 2 security to restrict application access to local resources option is enabled and if an application requires more Java 2 security permissions than are granted in the default policy, the application might fail to run properly until the required permissions are granted in either the app.policy file or the was.policy file of the application. AccessControl exceptions are generated by applications that do not have all the required permissions. See the related links for more information about Java 2 security.

Default: Disabled

Disabling security if you have server startup problems

Warn if applications are granted custom permissions

Specifies that during application deployment and application start, the security runtime issues a warning if applications are granted any custom permissions. Custom permissions are permissions that are defined by the user applications, not Java API permissions. Java API permissions are permissions in the java.* and javax.* packages.

The application server provides support for policy file management. A number of policy files are available in this product, some of them are static and some of them are dynamic. Dynamic policy is a template of permissions for a particular type of resource. No code base is defined and no relative code base is used in the dynamic policy template. The real code base is dynamically created from the configuration and run-time data. The filter.policy file contains a list of permissions that you do not want an application to have according to the J2EE 1.4 specification. For more information on permissions, see the related link about Java 2 security policy files.

Important: You cannot enable this option without enabling the Use Java 2 security to restrict application access to local resources option.
Default: Disabled

Restrict access to resource authentication data

Enable this option to restrict application access to sensitive Java Connector Architecture (JCA) mapping authentication data.

Consider enabling this option when both of the following conditions are true:
  • Java 2 security is enforced.
  • The application code is granted the accessRuntimeClasses WebSphereRuntimePermission permission in the was.policy file found within the application enterprise archive (EAR) file. For example, the application code is granted the permission when the following line is found in your was.policy file:
    permission com.ibm.websphere.security.WebSphereRuntimePermission "accessRuntimeClasses";

The Restrict access to resource authentication data option adds fine-grained Java 2 security permission checking to the default principal mapping of the WSPrincipalMappingLoginModule implementation. You must grant explicit permission to Java 2 Platform, Enterprise Edition (J2EE) applications that use the WSPrincipalMappingLoginModule implementation directly in the Java Authentication and Authorization Service (JAAS) login when Use Java 2 security to restrict application access to local resources and the Restrict access to resource authentication data options are enabled.

Default: Disabled

Current realm definition

Specifies the current setting for the active user repository.

This field is read-only.

Available realm definitions

Specifies the available user account repositories.

Set as current

Enables the user repository after it is configured.

You can configure settings for one of the following user repositories:
Federated repositories
Specify this setting to manage profiles in multiple repositories under a single realm. The realm can consist of identities in:
  • The file-based repository that is built into the system
  • One or more external repositories
  • Both the built-in, file-based repository and in one or more external repositories
Note: Only a user with administrator privileges can view the federated repositories configuration.
Local operating system

Specify this setting if you want your configured Resource Access Control Facility (RACF) or System Authorization Facility (SAF)-compliant security server used as the application server user registry.

Standalone LDAP registry

Specify this setting to use standalone LDAP registry settings when users and groups reside in an external LDAP directory. When security is enabled and any of these properties change, go to the Security > Secure administration, applications, and infrastructure panel and click Apply or OK to validate the changes.

Note: Since multiple LDAP servers are supported, this setting does not imply one LDAP registry.
Standalone custom registry
Specify this setting to implement your own standalone custom registry that implements the com.ibm.websphere.security.UserRegistry interface. When security is enabled and any of these properties change, go to the Secure administration, applications, and infrastructure panel and click Apply or OK to validate the changes.
Default: Disabled

Use domain-qualified user names

Specifies that user names that are returned by methods are qualified with the security domain in which they reside.

This field enables or disables qualifying user names with the security domain ID.

Default: Disabled

Active protocol

Specifies the active authentication protocol for Remote Method Invocation over the Internet Inter-ORB Protocol (RMI IIOP) requests, when security is enabled.

An Object Management Group (OMG) protocol called Common Secure Interoperability Version 2 (CSIv2) supports increased vendor interoperability and additional features. If all of the servers in your security domain are Version 5.x and later servers, specify CSI as your protocol.

[This information applies to Version 6.0.x and previous servers only that are federated in a Version 6.1 cell.] If some servers are Version 4.x servers, specify CSI and zSAS.
Important: z/SAS is supported only between Version 6.0.x and previous version servers that have been federated in a Version 6.1 cell.
[This information applies to Version 6.0.x and previous servers only that are federated in a Version 6.1 cell.] Note: This field displays only when a Version 6.0.x and earlier server is detected in your environment.
Default: BOTH
Range: CSI and zSAS, CSI

Custom Properties

For an existing configuration, you must modify a number of profiles. To modify the profiles, click Security > Secure administration, applications, and infrastructure > Custom properties.

"security.zOS.domainName" value="TESTSYS"
You can modify the following domain-related security custom properties:
  • The security.zOS.domainType property specifies whether a security domain is used to qualify security definitions. In the application server for z/OS, the values can be specified as none, which indicates that System Authorization Facility (SAF) security definitions are of the global sysplex scope or cellQualified . This value indicates that the application server runtime uses the domain name that is specified in the security.zOS.domainName property to qualify SAF security definitions. If the property is not defined, or a value is not set, none is assumed. For example: "security.zOS.domainType" value="cellQualified".
  • security.zOS.domainName is specified if "security.zOS.domainType" value="cellQualified". The value for security.zOS.domainName must be an upper case string from 1 to 8 characters in length, which is used to qualify SAF profiles checked for authorization for the server. If a value is specified here and cellQualified is selected, the name is also used to identify the application name used in the APPL and Passticket profiles. If a value for security.zOS.domainName is not specified, the default value is CBS390.
The following profiles are affected by this definition are:
  • EJBROLE (if SAF authorization)
  • CBIND
  • APPL
The customization dialog sets up appropriate SAF profiles during customization if the security domain is defined there. Changing the value of the domainType of domainName requires the customer to make appropriate changes in their SAF profile setup, otherwise runtime errors occur. For more information on the specific profile updates required for security domainName related customization and the security domain customization panels, see the related link about Summary of controls in the information center.



Related concepts
Java 2 security
Related tasks
Securing specific application servers
Enabling security
Related reference
Authentication mechanisms and expiration
Local operating system settings
Standalone LDAP registry settings
Summary of controls
Standalone custom registry settings
Administrative roles
Directory conventions
Java 2 security policy files
Summary of controls
Reference topic Reference topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 12:02:36 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-zos&topic=usec_secureadminappinfra
File name: usec_secureadminappinfra.html