13-4 Securing Oracle WebLogic Server
■
In the Remote Domain field, enter the name of the remote domain that needs to interact with the local domain.
4. Click Next.
5.
On the Create a New Security Credential Map Entry page, enter the following:
■
Local User : cross-domain
■
Remote User : User configured in the Remote Domain that is authorized to
interact with the Local Domain.
■
Password : The password for the Remote User.
6. Click Finish.
See Create a Cross-Domain Security Credential Mapping in the Oracle WebLogic Server Administration Console Help.
13.2.2 Enabling Global Trust
WebLogic Server enables you to establish global trust between two or more domains. You do this by specifying the same Domain Credential for each of the domains. By
default, the Domain Credential is randomly generated and therefore, no two domains will have the same Domain Credential. If you want two WebLogic domains to
interoperate, you need to replace the generated credential with a credential you select, and set the same credential in each of the domains. For configuration information, see
Enable global trust between domains in the Oracle WebLogic Server Administration Console Help.
If you enable global trust between two domains, the trust relationship is transitive and symmetric. In other words, if Domain A trusts Domain B and Domain B trusts Domain
C, then Domain A will also trust Domain C and Domain B and Domain C will both trust Domain A. In most cases, the credential mapper approach, described in
Section 13.2.1, Enabling Cross Domain Security Between WebLogic Server Domains, is preferable to the global trust approach, because it is provides closer control over
access. Global trust between domains is established so that principals in a Subject from one
WebLogic domain are accepted as principals in another domain. When this feature is enabled, identity is passed between WebLogic domains over an RMI connection
without requiring authentication in the second domain for example: log in to Domain 1 as Joe, make an RMI call to Domain 2 and Joe is still authenticated. WebLogic Server
signs Principals with the Domain Credential as Principals are created. When a Subject is received from a remote source, its Principals are validated the signature is recreated
and if it matches, the remote domain has the same Domain Credential. If validation fails, an error is generated. If validation succeeds, the Principals are trusted as if they
were created locally.
Caution: Enabling Global Trust between WebLogic domains has the
potential to open the servers up to man-in-the-middle attacks. Great care should be taken when enabling trust in a production
environment. Oracle recommends having strong network security such as a dedicated communication channel or protection by a strong
firewall.
Configuring Security for a WebLogic Domain 13-5
If you are enabling global trust between domains in a Managed Server environment, you must stop the Administration Server and all the Managed Servers in both
domains and then restart them. If this step is not performed, servers that were not rebooted will not trust the servers that were rebooted.
Keep the following points in mind when enabling global trust between WebLogic domains:
■
Because a domain will trust remote Principals without requiring authentication, it is possible to have authenticated users in a domain that are not defined in the
domains authentication database. This situation can cause authorization problems.
■
Any authenticated user in a domain can access any other domain that has trust enabled with the original domain without re-authenticating. There is no auditing
of this login and group membership is not validated. Therefore, if Joe is a member of the Administrators group in the original domain where he authenticated, he is
automatically a member of the Administrators group for all trusted domains to which he makes RMI calls.
■
If Domain 2 trusts both Domain 1 and Domain 3, Domain 1 and Domain 3 now implicitly trust each other. Therefore, members of the Administrators Group in
Domain 1 are members of the Administrators group in Domain 3. This may not be a desired trust relationship.
■
If you extended the WLSUser and WLSGroup Principal classes, the custom Principal classes must be installed in the servers classpath in all domains that
share trust.
To avoid these issues, Oracle recommends that rather than enabling global trust between two domains, you should instead configure users with the
CrossDomainConnector role and use the credential mapping approach described in Section 13.2.1, Enabling Cross Domain Security Between WebLogic Server Domains.
13.3 Using Connection Filters
Connection filters allow you to deny access at the network level. They can be used to protect server resources on individual servers, server clusters, or an entire internal
network or intranet. For example, you can deny any non-SSL connections originating outside of your corporate network. Network connection filters are a type of firewall in
that they can be configured to filter on protocols, IP addresses, and DNS node names.
Connection filters are particularly useful when using the Administration port. Depending on your network firewall configuration, you may be able to use a
connection filter to further restrict administration access. A typical use might be to restrict access to the Administration port to only the servers and machines in the
domain. An attacker who gets access to a machine inside the firewall, still cannot perform administration operations unless the attacker is on one of the permitted
machines.
WebLogic Server provides a default connection filter called weblogic.security.net.ConnectionFilterImpl. This connection filter
accepts all incoming connections and also provides static factory methods that allow the server to obtain the current connection filter. To configure this connection filter to
Note: Any credentials in clear text are encrypted the next time the
config.xml file is persisted to disk.
