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.
To view this administrative console page, click Security > Global security.
Security has some performance impacts on
your applications. The performance impacts can vary depending upon
the application workload characteristics. You must first determine
that the needed level of security is enabled for your applications,
and then measure the impact of security on the performance of your
applications.
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.
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.
Launches a report that gathers and displays the current security settings of the application server. Information is gathered about core security settings, administrative users and groups, CORBA naming roles, and cookie protection. When multiple security domains are configured the report displays the security configuration associated with each domain.
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.
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 links for administrative roles and administrative authentication.
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.
You can only specify the the z/OS® started
task option when the user registry is Local OS.
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 |
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 |
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 |
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.
Default: | Disabled |
Enable this option to restrict application access to sensitive Java Connector Architecture (JCA) mapping authentication data.
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 |
Specifies the current setting for the active user repository.
This field is read-only.
Specifies the available user account repositories.
Enables the user repository after it is configured.
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.
You cannot
use localOS in multi-node or when running as non-root on a UNIX® platform.
The local operating
system registry is valid only when you use a domain controller or
the WebSphere Application Server, Network Deployment cell resides on a single machine. In the later
case, you cannot spread multiple nodes in a cell across multiple machines
as this configuration, using the local OS user registry, is not valid.
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 > Global security panel and click Apply or OK to validate the changes.
Default: | Disabled |
Select to configure the global security settings.
Under Authentication, expand Web and SIP security to view links to:
Select to specify the settings for Web authentication.
Select to specify the configuration values for single sign-on (SSO).
With SSO support, Web users can authenticate once when accessing both WebSphere Application Server resources, such as HTML, JavaServer Pages (JSP) files, servlets, enterprise beans, and Lotus® Domino® resources.
Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) provides a way for Web clients and the server to negotiate the web authentication protocol that is used to permit communications.
Select to specify the settings for the trust association. Trust association is used to connect reversed proxy servers to the application servers.
You can use the global security settings or customize the settings for a domain.
Under Authentication, expand RMI/IIOP security to view links to:
Select to specify authentication settings for requests that are received and transport settings for connections that are accepted by this server using the Object Management Group (OMG) Common Secure Interoperability (CSI) authentication protocol.
Select to specify authentication settings for requests that are sent and transport settings for connections that are initiated by the server using the Object Management Group (OMG) Common Secure Interoperability (CSI) authentication protocol.
Under Authentication, expand Java authentication and authorization service to view links to:
Select to define login configurations that are used by JAAS.
Do not remove the ClientContainer, DefaultPrincipalMapping, and WSLogin login configurations because other applications might use them. If these configurations are removed, other applications might fail.
Select to define the JAAS login configurations that are used by system resources, including the authentication mechanism, principal mapping, and credential mapping.
Select to specify the settings for the Java Authentication and Authorization Service (JAAS) Java 2 Connector (J2C) authentication data.
You can use the global security settings or customize the settings for a domain.
Select to encrypt authentication information so that the application server can send the data from one server to another in a secure manner.
The encryption of authentication information that is exchanged between servers involves the Lightweight Third-Party Authentication (LTPA) mechanism.
Select to encrypt authentication information so that the application server can send the data from one server to another in a secure manner.
Select to encrypt authentication information so that the application server can send data from one server to anther in a secure manner.
The encryption of the authentication information that is exchanged between servers involves the KRB5 of LTPA mechanism.
Select to set your authentication cache settings.
Specifies that user names that are returned by methods, such as the getUserPrincipal() method, are qualified with the security realm in which they reside.
Use the Security Domain link to configure additional security configurations for user applications.
For example, if you want use a different user registry for a set of user applications than the one used at the global level, you can create a security configuration with that user registry and associate it with that set of applications. These additional security configurations can be associated with various scopes (cell, clusters/servers, SIBuses). Once the security configurations have been associated with a scope all of the user applications in that scope use this security configuration. Read about Multiple security domains for more detailed information.
For each security attribute, you can use the global security settings or customize settings for the domain.
Select to specify whether to use the default authorization configuration or an external authorization provider.
The external providers must be based on the Java uthorization Contract for Containers (JACC) specification to handle the Java(TM) 2 Platform, Enterprise Edition (J2EE) authorization. Do not modify any settings on the authorization provider panels unless you have configured an external security provider as a JACC authorization provider.
Select to specify name-value pairs of data, where the name is a property key and the value is a string.