File name: tsec_sec_domains_copy.html
Copying multiple security domains
You can copy selected multiple security domains from the
domain collection to create a new domain. This is useful if you want
to create a domain that is similar to a previous domain. However,
you might want to make a few slight adjustments. When copying an existing
domain, you must supply a unique domain name for the new one.
Before you begin
Only users assigned to the administrator role can copy
or create new multiple security domains. Enable global security in
your environment before copying multiple security domains.
Read about Multiple security domains for a
better understanding of what multiple security domains are and how
they are supported in this version of WebSphere® Application
Server.
About this task
Security domains provide a mechanism to use different
security settings for administrative applications and user applications.
They also provide the ability to support multiple security settings
so different applications can use different security attributes like
user registry or login configurations.
Use multiple security
domains to achieve the following goals:
- Configure different security attributes for administrative and
user applications within a cell
- Consolidate server configurations by managing different security
configurations within a cell
- Restrict access between applications with different user registries,
or configure trust relationships between applications to support communication
across registries
Perform the following steps to copy an existing security
domain using the administrative console:
Procedure
- Click Security > Security domains.
- Optional: From Preferences, you can select
the maximum number of rows to display when the domain collection is
large. The default number of rows is 20. Rows that exceed
that number appear on subsequent pages.
- Select a domain to copy.
- Click Copy Selected Domain... to copy an existing
domain from the collection. You can optionally select Copy
Global Security.. to copy an existing domain and have it maintain
its global security settings (collection selections are ignored).
A new domain name is also required if you choose this option.
- Specify a unique name for the domain. This field
is required. A domain name must be unique within a cell and cannot
contain an invalid character.
- Specify a unique description for the domain.
- Click Apply. After you click Apply you
are returned to the Security domains detail page
- Under Assigned Scopes, assign the security domain to the
entire cell or select the specific servers, clusters, and service
integration buses to include in the security domain.
- Customize your security configuration by specifying security
attributes for your new domain and by assigning it to cell resources.
You can change security attributes such as the following:
- Application Security
- Specifies the settings for application security and Java™ 2 security. You can use the global security
settings or customize the settings for a domain.
Select Enable
application security to enable or disable security this choice
for user applications. When this selection is disabled, all of the
EJBs and Web applications in the security domain are no longer protected.
Access is granted to these resources without user authentication.
When you enable this selection, the J2EE security is enforced for
all of the EJBs and Web applications in the security domain. The J2EE
security is only enforced when Global Security is enabled in the global
security configuration, (that is, you cannot enable application security
without first enabling Global Security at the global level).
- Java 2 Security
- Select Java 2 security to enable or
disable Java 2 security at the domain level.
This choice enables or disables Java 2
security at the process (JVM) level so that all applications (both
administrative and user) can enable or disable Java 2
security.
- User realm
This section enables you to configure the user registry for
the security domain. You can separately configure any registry except
the federated registry that is used at the domain level. The federated
repository can only be configured at the global level but can be used
at the domain level. Read about Multiple security domains for more
information.
- Trust association
- When you configure the trust association interceptor (TAI) at
a domain level, the interceptors configured at the global level are
copied to the domain level for convenience. You can modify the interceptor
list at the domain level to fit your needs. Only configure those interceptors
that are to be used at the domain level.
- SPNEGO Web Authentication
- The SPNEGO Web authentication, which enables you to configure
SPNEGO for Web resource authentication, can be configured at the domain
level.
Note: In WebSphere Application Server Version 6.1,
a TAI that uses the Simple and Protected GSS-API Negotiation Mechanism
(SPNEGO) to securely negotiate and authenticate HTTP requests for
secured resources was introduced. In WebSphere Application
Server 7.0, this function is now deprecated. SPNEGO Web authentication
has taken its place to provide dynamic reload of the SPNEGO filters
and to enable fallback to the application login method.
- RMI/IIOP Security
The RMI/IIOP security attribute refers to the CSIv2 (Common
Secure Interoperability version 2) protocol properties. When you configure
these attributes at the domain level, the RMI/IIOP security configuration
at the global level is copied for convenience.
You can change
the attributes that need to be different at the domain level. The
Transport layer settings for CSIv2 inbound communications should be
the same for both the global and the domain levels. If they are different,
the domain level attributes are applied to all of the application
in the process.
- JAAS application logins
- Specifies the configuration settings for the Java Authentication
and Authorization Service (JAAS) application logins. You can use the
global security settings or customize the settings for a domain.
The
JAAS application logins, the JAAS system logins, and the JAAS J2C
authentication data aliases can all be configured at the domain level.
Be default, all of the applications in the system have access to the
JAAS logins configured at the global level. The security runtime first
checks for the JAAS logins at the domain level. If it does not find
them, it then checks for them in the global security configuration.
Configure any of these JAAS logins at a domain only when you need
to specify a login that is used exclusively by the applications in
the security domain.
- JAAS system logins
- Specifies the configuration settings for the JAAS system logins.
You can use the global security settings or customize the configuration
settings for a domain.
The JAAS application logins, the JAAS system
logins, and the JAAS J2C authentication data aliases can all be configured
at the domain level. Be default, all of the applications in the system
have access to the JAAS logins configured at the global level. The
security runtime first checks for the JAAS logins at the domain level.
If it does not find them, it then checks for them in the global security
configuration. Configure any of these JAAS logins at a domain only
when you need to specify a login that is used exclusively by the applications
in the security domain.
- JAAS J2C authentication
- Specifies the configuration settings for the JAAS J2C authentication
data. You can use the global security settings or customize the settings
for a domain.
The JAAS application logins, the JAAS system logins,
and the JAAS J2C authentication data aliases can all be configured
at the domain level. Be default, all of the applications in the system
have access to the JAAS logins configured at the global level. The
security runtime first checks for the JAAS logins at the domain level.
If it does not find them, it then checks for them in the global security
configuration. Configure any of these JAAS logins at a domain only
when you need to specify a login that is used exclusively by the applications
in the security domain.
- Authentication Mechanism Attributes
Specifies the various cache settings that need to applied at
the domain level.
Select Authentication cache settings to
specify your authentication cache settings. The configuration specified
on this panel is applied only to this domain.
Select LTPA
Timeout to configure a different LTPA timeout value at the domain
level. The default timeout value is 120 minutes, which is set at the
global level. If the LTPA timeout is set at the domain level, any
token that is created in the security domain when accessing user applications
is created with this expiration time.
When Use realm-qualified
user names is enabled, user names returned by methods such as getUserPrincipal(
) are qualified with the security realm (user registry) used
by applications in the security domain.
- Authorization Provider
You can configure an external third party JACC (Java Authorization Contract for Containers)
provider at the domain level. Tivoli® Access Manager's
JACC provider can only be configured at the global level. Security
domains can still use it if they do not override the authorization
provider with another JACC provider or with the built-in native authorization.
![[z/OS]](../../ngzos.gif)
You can additionally configure the SAF authorization
options at the security domain level, which are the following:
- The unauthenticated user id
- The SAF profile mapper
- Whether to enable SAF delegation
- Whether to use the APPL profile to restrict access to WebSphere
Application Server
- Whether to suppress authorization failed messages
- The SMF audit record strategy
- The SAF profile prefix
- z/OS® security options
You can set z/OS specific security options
at the process (JVM) level so that all applications (both administrative
and user) can enable or disable these options. These properties are:
- Enabling application server and z/OS thread
identity synchronization
- Enabling the connection manager RunAs thread identity.
For more information on the z/OS security
options, read about z/OS security options
- Custom properties
- Set custom properties at the domain level that are either new
or different from those at the global level. By default, all of the
custom properties at the global security configuration can be accessed
by all of the applications in the cell. The security runtime code
first checks for the custom property at the domain level. If it does
not find it, it then attempts to obtain the custom property from the
global security configuration.
- Click Apply.
- After you have saved your configuration changes, restart
the server for your changes to take effect.
In this information ...
| IBM Redbooks, demos, education, and more(Index)
Most of the following links will take you to information that is not part of the formal product documentation and is provided "as is." Some of these links go to non-IBM Web sites and are provided for your convenience only and do not in any manner serve as an endorsement by IBM of those Web sites, the material thereon, or the owner thereof.
|
|
