Securing WebLogic Server
The following sections provide an overview of the security system for WebLogic Server. For a broader overview, see Understanding WebLogic Security.
The security service in WebLogic Server simplifies the configuration and management of security while offering robust capabilities for securing your WebLogic Server deployment. Security realms act as a scoping mechanism. Each security realm consists of a set of configured security providers, users, groups, security roles, and security policies. You can configure multiple security realms in a domain; however, only one can be the active security realm. WebLogic Server provides two default security realms:
myrealm—Has the WebLogic Adjudication, Authentication, Identity Assertion, Authorization, Role Mapping, and Credential Mapping providers configured by default.
CompatibilityRealm—Provides backward compatibility for 6.x security configurations. You can access an existing 6.x security configuration through the
You can customize authentication and authorization functions by configuring a new security realm to provide the security services you want and then set the new security realm as the default security realm.
For information about the default security configuration in WebLogic Server, see The Default Security Configuration in WebLogic Server.
For information about configuring a security realm and setting it as the default security realm, see Customizing the Default Security Configuration.
For information about Compatibility security, see Using Compatibility Security.
Security providers are modular components that handle specific aspects of security, such as authentication and authorization. Although applications can leverage the services offered by the default WebLogic security providers, the WebLogic Security Service's flexible infrastructure also allows security vendors to write their own custom security providers for use with WebLogic Server. WebLogic security providers and custom security providers can be mixed and matched to create unique security solutions, allowing organizations to take advantage of new technology advances in some areas while retaining proven methods in others. The WebLogic Administration Console allows you to administer and manage all your security providers through one unified management interface.
Note: The WebLogic Server Keystore provider is deprecated and is only supported for backward compatibility. Use keystores instead. For more information about configuring keystores, see Configuring Keystores for Production.
For information about the default security configuration, see The Default Security Configuration in WebLogic Server.
For information about writing custom security providers, see Developing Security Providers for WebLogic Server.
WebLogic Server uses security policies (which replace the ACLs and permissions used in WebLogic Server 6.x) to protect WebLogic resources. Security policies answer the question "who has access" to a WebLogic resource. A security policy is created when you define an association between a WebLogic resource and a user, group, or security role. You can also optionally associate a time constraint with a security policy. A WebLogic resource has no protection until you assign it a security policy.
Creating security policies is a multi-step process with many options. To fully understand this process, read Securing WebLogic Resources. That document should be used in conjunction with Securing WebLogic Security to ensure security is completely configured for a WebLogic Server deployment.
web-services.xmlfile, and so on).
WebLogic Server offers a choice of models for configuring security roles and policies. Under the standard Java Enterprise Edition model, you define role mappings and policies in the Web application or EJB deployment descriptors. The WebLogic Security Service can use information defined in deployment descriptors to grant security roles and define security policies for Web applications and EJBs. When WebLogic Server is booted for the first time, security role and security policy information stored in
weblogic-ejb-jar.xml deployment descriptors is loaded into the Authorization and Role Mapping providers configured in the default security realm. You can then make changes to the information through the Administration Console.
To use information in deployment descriptors, at least one Authorization and Role Mapping provider in the security realm must implement the
DeployableRoleProvider Security Service Provider Interface (SSPI). This SSPI allows the providers to store (rather than retrieve) information from deployment descriptors. By default, the WebLogic Authorization and Role Mapping providers implement this SSPI.
If you change security role and security policy in deployment descriptors through the Administration Console and want to continue to modify this information through the Administration Console, you can set configuration options on the security realm to ensure changes made through the Console are not overwritten by old information in the deployment descriptors when WebLogic Server is rebooted.
For more information, see "Options for Securing Web Application and EJB Resources in Securing WebLogic Resources.
To simplify the configuration and management of security, WebLogic Server provides a default security configuration. In the default security configuration,
myrealm is set as the default security realm and the WebLogic Adjudication, Authentication, Identity Assertion, XACML Authorization, Credential Mapping, XACML Role Mapping, and CertPath providers are defined as the security providers. WebLogic Server's embedded LDAP server is used as the data store for these default security providers. To use the default security configuration, you need to define users, groups, and security roles for the security realm, and create security policies to protect the WebLogic resources in the domain.
Note: WebLogic Server includes the WebLogic Authorization provider, which is referred to in the Administration Console and elsewhere as the Default Authorizer, and the WebLogic Role Mapping provider, which is referred to in the Administration Console and elsewhere as the Default RoleMapper. Beginning with WebLogic Server 9.1, these providers are no longer the default providers in newly-created security realms. Instead, the XACML Authorization provider and the XACML Role Mapping provider are the default providers.
For a description of the functionality provided by the WebLogic Security providers, see Understanding WebLogic Security. If the WebLogic security providers do not fully meet your security requirements, you can supplement or replace them. See Developing Security Providers for WebLogic Server.
If the default security configuration does not meet your requirements, you can create a new security realm with any combination of WebLogic and custom security providers and then set the new security realm as the default security realm. See Customizing the Default Security Configuration.
Because WebLogic Server's security features are closely related, it is difficult to determine where to start when configuring security. In fact, configuring security for your WebLogic Server deployment may be an iterative process. Although more than one sequence of steps may work, BEA Systems recommends the following procedure:
myrealm). For information about the circumstances that require you to customize the default security configuration, see Why Customize the Default Security Configuration?. For information about creating custom security providers, see Developing Security Providers for WebLogic Server.
Note: You can also create a new security realm, configure security providers (either WebLogic or custom) in the security realm and set the new security realm as the default security realm. See Customizing the Default Security Configuration.
In many cases, this document describes how to configure WebLogic security by using the WebLogic Server Administration Console. Generally, any configuration task you can accomplish through the Console you can also accomplish by using the WebLogic Scripting Tool or the Java Management Extensions (JMX) APIs. For information about using WLST to manage WebLogic security, see Managing Security in WebLogic Scripting Tool. For information about using JMX APIs, see Choosing an MBean Server to Manage Security Realms in Developing Custom Management Utilities with JMX.
In addition, to prevent the possibility of incompatible changes, you cannot invoke operations in security provider MBeans if your client or another JMX client has an edit session currently active. The Administration Console automatically enforces this limitation and automatically accesses the proper MBean server. When you use the Console, you can override this limitation by enabling Allow Security Management Operations if Non-dynamic Changes have been Made on the Domain: Security: General page. Setting this attribute to true permits users to perform security management operations without restarting the server. Note that this attribute is reset to false when a new MBean edit session begins.
For example, the value of the
MinimumPasswordLength attribute in
DefaultAuthenticatorMBean is stored in the domain's configuration document. Because all modifications to this document are controlled by WebLogic Server, to change the value of this attribute you must use the Edit MBean Server and acquire a lock on the domain's configuration. The
createUser operation in
DefaultAuthenticatorMBean adds data to an LDAP server, which is not controlled by WebLogic Server. To prevent incompatible changes between the
DefaultAuthenticatorMBean's configuration and the data that it uses in the LDAP server, you cannot invoke the
createUser operation if you or other users are in the process of modifying the
MinimumPasswordLength attribute. In addition, because changing this attribute requires you to restart WebLogic Server, you cannot invoke the
createUser operation until you have restarted the server.
Compatibility security refers to the capability to run security configurations developed under WebLogic Server 6.x in this release of WebLogic Server. In Compatibility security, you manage 6.x security realms, users, groups, and ACLs, protect user accounts, and configure the Realm Adapter Auditing provider and optionally the Identity Assertion provider in the Realm Adapter Authentication provider.
The only security realm available in Compatibility security is the
CompatibilityRealm. The Realm Adapter providers (Auditing, Adjudication, Authorization, and Authentication) in the Compatibility realm allow backward compatibility with the authentication, authorization, and auditing services in 6.x security realms. For more information, see Using Compatibility Security.
Note: Compatibility security is deprecated and will not be supported in future major releases. BEA strongly recommends upgrading your WebLogic Server deployment to the security features in this release of WebLogic Server. You should only use Compatibility security pending such an upgrade.
Because Compatibility security allows you to access only authentication, authorization, and custom auditing implementations supported in WebLogic Server 6.x, not all 6.x security tasks are allowed in Compatibility security. Use Compatibility security to:
weblogic.security.acl.CertAuthenticatorclass can be used. For more information, see Configuring the Identity Assertion Provider in the Realm Adapter Authentication Provider.
Note: The Realm Adapter Adjudication and Authorization providers are configured by default in the
CompatibilityRealm using information in an 6.x existing
config.xml file. These providers can only be used in the
CompatibilityRealm. The Realm Adapter Authentication provider is also automatically configured in the
CompatibilityRealm. However, this provider can also be configured in other realms to provide access to users and groups stored in 6.x security realms. For more information, see Configuring RDBMS Authentication Providers.
systemuser to protect your WebLogic Server deployment.
CompatibilityRealm. Organize users further by implementing groups in the security realm.
CompatibilityRealm. For more information, see Securing WebLogic Resources.
You can still configure identity and trust, use SSL, configure connection filters, and enable interoperability between domains; however, you use the security features available in this release of WebLogic Server to perform these tasks. See: