The task of managing WebLogic Server security focuses primarily on creating and configuring one or more security realms. In each security realm, you configure a set of security providers, create security policies for the WebLogic resources that need to be protected, select configuration options for protecting user accounts, and configure identity and trust.
This chapter includes the following sections:
For a broader overview of security management concepts, see Understanding Security for Oracle WebLogic Server.
Throughout this document, the term 6.x refers to WebLogic Server 6.0 and 6.1 and their associated service packs.
WebLogic Server provides a default security realm, myrealm, which has the WebLogic Adjudication, Authentication, Identity Assertion, Authorization, Role Mapping, and Credential Mapping providers configured by default.
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.
The WebLogic Security Service supports the following types of security providers:
Authentication—Authentication is the process whereby the identity of users or system processes are proved or verified. Authentication also involves remembering, transporting, and making identity information available to various components of a system when that information is needed. Authentication providers supported by the WebLogic Security Service supply the following types of authentication:
Username and password authentication
Certificate-based authentication directly with WebLogic Server
HTTP certificate-based authentication proxied through an external Web server
Identity Assertion—An Authentication provider that performs perimeter authentication—a special type of authentication using tokens—is called an Identity Assertion provider. Identity assertion involves establishing a client's identity through the use of client-supplied tokens that may exist outside of the request. Thus, the function of an Identity Assertion provider is to validate and map a token to a username. Once this mapping is complete, an Authentication provider's LoginModule can be used to convert the username to a principal (an authenticated user, group, or system process).
Authorization—Authorization is the process whereby the interactions between users and WebLogic resources are limited to ensure integrity, confidentiality, and availability. In other words, once a user's identity has been established by an authentication provider, authorization is responsible for determining whether access to WebLogic resources should be permitted for that user. An Authorization provider supplies these services.
Role Mapping—You can assign one or more roles to multiple users and then specify access rights for users who hold particular roles. A Role Mapping provider obtains a computed set of roles granted to a requestor for a given resource. Role Mapping providers supply Authorization providers with this information so that the Authorization provider can answer the "is access allowed?" question for WebLogic resources that use role-based security (for example, Web applications and Enterprise JavaBeans (EJBs)).
Adjudication—When multiple Authorization providers are configured in a security realm, each may return a different answer to the "is access allowed" question for a given resource. Determining what to do if multiple Authorization providers do not agree is the primary function of an Adjudication provider. Adjudication providers resolve authorization conflicts by weighing each Authorization provider's answer and returning a final access decision.
Credential Mapping—A credential map is a mapping of credentials used by WebLogic Server to credentials used in a legacy or remote system, which tell WebLogic Server how to connect to a given resource in that system. In other words, credential maps allow WebLogic Server to log into a remote system on behalf of a subject that has already been authenticated. Credential Mapping providers map credentials in this way.
Keystore—A keystore is a mechanism for creating and managing password-protected stores of private keys and certificates for trusted certificate authorities. The keystore is available to applications that may need it for authentication or signing purposes. In the WebLogic Server security architecture, the WebLogic Keystore provider is used to access keystores.
The WebLogic Server Keystore provider is removed and is only supported for backward compatibility. Use JDK keystore instead. For more information about configuring keystores, see Creating a Keystore.
Certificate Lookup and Validation (CLV)—X.509 certificates need to be located and validated for purposes of identity and trust. CLV providers receive certificates, certificate chains, or certificate references, complete the certificate path (if necessary), and validate all the certificates in the path. There are two types of CLV providers:
A CertPath Builder looks up and optionally completes the certificate path and validates the certificates.
A CertPath Validator looks up and optionally completes the certificate path, validates the certificates, and performs extra validation (for example, revocation checking).
Certificate Registry—A certificate registry is a mechanism for adding certificate revocation checking to a security realm. The registry stores a list of valid certificates. Only registered certificates are valid. A certificate is revoked by removing it from the certificate registry. The registry is stored in the embedded LDAP server. The Certificate Registry is both a CertPath Builder and a CertPath Validator.
Auditing—Auditing is the process whereby information about security requests and the outcome of those security requests is collected, stored, and distributed for the purpose of non-repudiation. In other words, auditing provides an electronic trail of computer activity. An Auditing provider supplies these services.
For information about the functionality provided by the WebLogic security providers, see About Configuring WebLogic Security Providers and About Configuring the Authentication Providers in WebLogic Server.
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 Oracle WebLogic Server.
Creating security policies is a multi-step process with many options. To fully understand this process, read Securing Resources Using Roles and Policies for Oracle WebLogic Server. That document should be used in conjunction with Securing WebLogic Security to ensure security is completely configured for a WebLogic Server deployment.
This section includes the following topics:
A WebLogic resource is a structured object used to represent an underlying WebLogic Server entity, which can be protected from unauthorized access. WebLogic Server defines the following resources:
Administrative resources such as the WebLogic Server Administration Console and WebLogic Scripting Tool.
Application resources that represent Enterprise applications. This type of resource includes individual EAR (Enterprise Application aRchive) files and individual components, such as EJB JAR files contained within the EAR.
Component Object Model (COM) resources that are designed as program component objects according to Microsoft's framework. This type of resource includes COM components accessed through the Oracle bidirectional COM-Java (jCOM) bridging tool.
Enterprise Information System (EIS) resources that are designed as resource adapters, which allow the integration of Java applications with existing enterprise information systems. These resource adapters are also known as connectors.
Enterprise JavaBean (EJB) resources including EJB JAR files, individual EJBs within an EJB JAR, and individual methods on an EJB.
Java DataBase Connectivity (JDBC) resources including groups of connection pools, individual connection pools, and multipools.
Java Naming and Directory Interface (JNDI) resources.
Java Messaging Service (JMS) resources.
Server resources related to WebLogic Server instances, or servers. This type of resource includes operations that start, shut down, lock, or unlock servers.
URL resources related to Web applications. This type of resource can be a Web Application aRchive (WAR) file or individual components of a Web application (such as servlets and JSPs).
Web resources are deprecated. Use the URL resource instead.
Web services resources related to services that can be shared by and used as components of distributed, Web-based applications. This type of resource can be an entire Web service or individual components of a Web service (such as a stateless session EJB, particular methods in that EJB, the Web application that contains the
web-services.xml file, 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 view the role and policy information from the WebLogic Server Administration Console. (Optionally, you may configure the security realm to use a different security model that allows you to make changes to that information via the WebLogic Server Administration Console as well.)
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 WebLogic Server Administration Console and want to continue to modify this information through the WebLogic Server 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.
See Options for Securing Web Application and EJB Resources in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
myrealmis 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 in that realm. 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.
WebLogic Server includes the WebLogic Authorization provider, which is referred to in the WebLogic Server Administration Console and elsewhere as the Default Authorizer, and the WebLogic Role Mapping provider, which is referred to in the WebLogic Server 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 Security for Oracle WebLogic Server. If the WebLogic security providers do not fully meet your security requirements, you can supplement or replace them. See Developing Security Providers for Oracle 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.
If you plan to use WebLogic Server in a production environment, make sure you do the following:
Secure the host environment prior to installing WebLogic Server, as explained in Performing a Secure Installation of WebLogic Server.
When creating the WebLogic domain, configure the domain to run in production mode or secured production mode, as explained in Creating a WebLogic Domain for Production Use.
Immediately after starting the domain for the first time, complete the tasks described in Securing the Domain After You Have Created It.
Determine whether or not to use the default security configuration by reading Why Customize the Default Security Configuration?
If you are using the default security configuration, begin at step 3.
If you are not using the default security configuration, begin at step 2.
Configure additional security providers (for example, configure an LDAP Authentication provider instead of using the WebLogic Authentication provider) or configure custom security providers in the default security realm. This step is optional. By default, WebLogic Server configures the WebLogic security providers in the default security realm (
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 Overview of the Development Process in Developing Security Providers for Oracle WebLogic Server.
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.
Optionally, configure the embedded LDAP server. WebLogic Server's embedded LDAP server is configured with default options. However, you may want to change those options to optimize the use of the embedded LDAP server in your environment. See Managing the Embedded LDAP Server.
Ensure that user accounts are properly secured. WebLogic Server provides a set of configuration options for protecting user accounts. By default, they are set for maximum security. However, during the development and deployment of WebLogic Server, you may need to weaken the restrictions on user accounts. Before moving to production, check that the options on user accounts are set for maximum protection. If you are creating a new security realm, you need to set the user lockout options. See How Passwords Are Protected in WebLogic Server and Protecting User Accounts.
Protect WebLogic resources with security policies. Creating security policies is a multi-step process with many options. To fully understand this process and to ensure security is completely configured for a WebLogic Server deployment, read Securing Resources Using Roles and Policies for Oracle WebLogic Server and Administering Security for Oracle WebLogic Server 12c.
Configure identity and trust for WebLogic Server. (This step is optional but strongly recommended, especially for production environments.) See Configuring Keystores.
Enable SSL for WebLogic Server. (This step is also optional, but strongly recommended for all production environments.) See Setting Up SSL: Main Steps.
When you have moved to production, review and implement the additional security options described in Securing a Production Environment for Oracle WebLogic Server.
In addition, you can:
Configure a connection filter. See Using Connection Filters.
Enable interoperability between WebLogic domains. See Configuring Cross-Domain Security.
Generally, any configuration task you can accomplish through the console you can also accomplish by using WLST, REST, or JMX. The following table shows where you can get information about using those tools as an alternative to the WebLogic Server Administration Console for configuring security:
|For information about using . . .||. . . see the following topics|
Managing Security Data (WLST Online) in Understanding the WebLogic Scripting Tool
Fusion Middleware Control
WebLogic Server Security in Administering Oracle WebLogic Server with Fusion Middleware Control
Using the WLS RESTful Management Interface in Administering Oracle WebLogic Server with RESTful Management Services
Choosing an MBean Server to Manage Security Realms in Developing Custom Management Utilities Using JMX for Oracle WebLogic Server
When you manage security realms, you must use two different MBean servers depending on your task:
To set the value of a security MBean attribute, you must use the Edit MBean Server.
To add users, groups, roles, and policies, or to invoke other operations in a security provider MBean, you must use a Runtime MBean Server or the Domain Runtime MBean Server.
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 WebLogic Server Administration Console automatically enforces this limitation and automatically accesses the proper MBean server. When you use the WebLogic Server Administration Console, you can override this limitation by selecting the Domain > Security > General page and enabling Allow Security Management Operations if Non-dynamic Changes have been Made. 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.
The web services password digest feature in the WebLogic Authentication provider does not use hashed passwords. Instead, reversible encryption is used so that password digests can be computed at runtime. (Password digest authentication is not supported for servlets and web application.) For information about the Enable Password Digests attribute, see Default Authentication Provider: Provider Specific in Oracle WebLogic Server Administration Console Online Help.
SerializedSystemIni.dat file contains the primary encryption key for the domain. It is associated with a specific WebLogic domain so it cannot be moved from domain to domain.
Sensitive configuration data, including such items as JDBC passwords, is encrypted with the primary encryption key. This encrypted data is kept in
config.xml, or in the security metadata/policy store in the embedded LDAP. (RDBMS is used if configured.)
SerializedSystemIni.dat file is destroyed or corrupted, you must reconfigure the WebLogic domain. Therefore, you should take the following precautions:
Make a backup copy of the
SerializedSystemIni.dat file and put it in a safe location.
Set permissions on the
SerializedSystemIni.dat file such that the system administrator of a WebLogic Server deployment has write and read privileges and no other users have any privileges.