10 Understanding WebLogic Server Security

WebLogic Server includes a security architecture that provides a unique and secure foundation for applications. By taking advantage of the security features in WebLogic Server, enterprises benefit from a comprehensive, flexible security infrastructure designed to address the security challenges of making applications available on the web.

This chapter includes the following topics:


For a complete checklist of critical tasks for locking down WebLogic Server, including specific tasks recommended for configuring a secure domain, securing the network, files, and databases used by WebLogic Server, see Securing a Production Environment for Oracle WebLogic Server.

JSR 375 Security API Support in WebLogic Server

WebLogic Server provides full support for the JSR 375 Java EE Security API 1.0, a new security feature of Java EE 8.

The Java EE Security API defines portable authentication mechanisms (such as HttpAuthenticationMechanism and IdentityStore), and an access point for programmatic security using the SecurityContext interface. These portable, plug-in authentication and identity store interfaces provide an advantage over container-provided implementations because they allow the application to control the authentication process and the identity stores used for that authentication in a standard and portable way. Bundling the security configuration in the application, instead of configuring it externally, improves the management of the application’s lifecycle, especially in a world of microservices that are distributed in containers. You can use the built-in implementations of these APIs, or define custom implementations.

In WebLogic Server, these authentication mechanisms are supported in the web container, and the SecurityContext interfaces are supported in the Servlet and EJB containers. WebLogic Server also supports the requirement in the Security API that group principal names are mapped to roles of the same name by default.

The Java EE Security API 1.0 (JSR 375) is defined in the specification at https://www.jcp.org/en/jsr/detail?id=375?id=375.

For more information about the Java EE Security API (JSR 375) in WebLogic Server, see Using the Java EE Security API in Developing Applications with the WebLogic Security Service.

Overview of the WebLogic Server Security Service

WebLogic Server includes a security architecture that provides a unique and secure foundation for applications that are available through the Internet. By taking advantage of the security features in WebLogic Server, enterprises benefit from a comprehensive, flexible security infrastructure designed to address the security challenges of making applications publicly available.

WebLogic security can be used standalone to secure WebLogic Server applications or as part of an enterprise-wide, security management system that represents a best-in-breed, security management solution. The key features of the WebLogic Security Service include:

  • A comprehensive and standards-based design.

  • End-to-end security for WebLogic Server-hosted applications, from the mainframe to the web browser.

  • Legacy security schemes that integrate with WebLogic Server security, allowing companies to leverage existing investments.

  • Security tools that are integrated into a flexible, unified system to ease security management across the enterprise.

  • Easy customization of application security to business requirements through mapping of company business rules to security policies.

  • A consistent model for applying security policies to Java EE and application-defined resources.

  • Easy updates to security policies. This release includes usability enhancements to the process of creating security policies as well as additional expressions that control access to WebLogic resources.

  • Easy adaptability for customized security solutions.

  • A modularized architecture, so that security infrastructures can change over time to meet the requirements of a particular company.

  • Support for configuring multiple security providers, as part of a transition scheme or upgrade path.

  • A separation between security details and application infrastructure, making security easier to deploy, manage, maintain, and modify as requirements change.

  • Default WebLogic security providers that provide you with a working security scheme out of the box. This release supports additional authentication stores such as databases and gives the option to configure an external RDBMS system as a datastore to be used by select security providers.

  • Customization of security schemes using custom security providers.

  • Unified management of security rules, security policies, and security providers through the WebLogic Server Administration Console.

  • Support for standard Java EE security technologies such as the Java Authentication and Authorization Service (JAAS), Java Secure Sockets Extensions (JSSE), Java Cryptography Extensions (JCE), Java Authorization Contract for Containers (JACC), Java Authentication Service Provider Interface for Containers (JASPIC), and the Java EE Security API (JSR 375).

  • A foundation for web services security including support for Security Assertion Markup Language (SAML) 1.1 and 2.0.

  • Capabilities which allow WebLogic Server to participate in single sign-on (SSO) with web sites, web applications, and desktop clients

  • A framework for managing public keys which includes a certificate lookup, verification, validation, and revocation as well as a certificate registry.

WebLogic Server Security Service Architecture

The WebLogic Server Security Service features a comprehensive and standards-based design that delivers end-to-end security for WebLogic Server-hosted applications from the mainframe to the web browser, easy customization of application security that can map of company business rules to security policies, a consistent model for applying security policies to Java EE and application-defined resources, and more.

This section provides a description of the architecture of the WebLogic Security Service. The architecture encompasses the following major components:

WebLogic Security Framework

Figure 10-1 shows a high-level view of the WebLogic Security Framework. The framework comprises interfaces, classes, and exceptions in the weblogic.security.service package.

Figure 10-1 WebLogic Security Service Architecture

Description of Figure 10-1 follows
Description of "Figure 10-1 WebLogic Security Service Architecture"

The primary function of the WebLogic Security Framework is to provide a simplified application programming interface (API) that can be used by security and application developers to define security services. Within that context, the WebLogic Security Framework also acts as an intermediary between the WebLogic containers (web and EJB), the resource containers, and the security providers.

Single Sign-on with the WebLogic Server Security Framework

Single sign-on (SSO) is the ability to require a user to sign on to an application only once and gain access to many different application components, even though these components may have their own authentication schemes. SSO enables users to log in securely to all their applications, web sites, and mainframe sessions with just one identity. The Security Assertion Markup Language (SAML) and Windows Integrated Authentication features provide web-based SSO functionality for WebLogic Server applications.

SAML Token Profile Support in WebLogic Web Services

The WebLogic web services and the WebLogic Security Framework support the generation, consumption, and validation of SAML 1.1 and 2.0 assertions. When using SAML assertions, a web service passes a SAML assertion and the accompanying proof material to the WebLogic Security Framework.If the SAML assertion is valid and trusted, the framework returns an authenticated Subject with a trusted principal back to the web service. WebLogic web services and the WebLogic Security Framework support the following SAML assertions:

  • Sender-Vouches - The asserting party (different from the subject) vouches for the verification of the subject. The receiver must have a trust relationship with the asserting party.

  • Holder-of-Key - The purpose of SAML token with "holder-of-key" subject confirmation is to allow the subject to use an X.509 certificate that may not be trusted by the receiver to protect the integrity of the request messages.

    Conceptually, the asserting party inserts an X.509 public certificate (or other key info) into a SAML assertion. (More correctly, the asserting party binds a key to a subject.) In order to protect this embedded certificate, the SAML assertion itself must be signed by the asserting entity. For WebLogic Server, the web service client signs the SAML assertion with its private key. That is, the signature on the assertion is the signature of the SAML authority, and is not based on the certificate contained in, or identified by, the assertion.

  • Bearer - The subject of the assertion is the bearer of the assertion, subject to optional constraints on confirmation using attributes that may be included in the <SubjectConfirmationData> element of the assertion.

The Security Service Provider Interfaces (SSPIs)

Security in WebLogic Server is based on a set of Security Service Provider Interfaces (SSPIs). The SSPIs can be used by developers and third-party vendors to develop security providers for the WebLogic Server environment. SSPIs are available for Adjudication, Auditing, Authentication, Authorization, Credential Mapping, Identity Assertion, Role Mapping, and Certificate Lookup and Validation.

The SSPIs allow customers to use custom security providers for securing WebLogic Server resources. Customers can use the SSPIs to develop custom security providers or they can purchase customer security providers from third-party vendors.

For more information on developing custom security providers, see Developing Security Providers for Oracle WebLogic Server.

WebLogic Security Providers

Security providers are modules that "plug into" a WebLogic Server security realm to provide security services to applications. They call into the WebLogic Security Framework on behalf of applications.

If the security providers supplied with the WebLogic Server product do not fully meet your security requirements, you can supplement or replace them with custom security providers. You develop a custom security provider by:

  • Implementing the appropriate security service provider interfaces (SSPIs) from the weblogic.security.spi package to create runtime classes for the security provider.

  • Creating an MBean Definition File (MDF) and using the WebLogic MBeanMaker utility to generate an MBean type, which is used to configure and manage the security provider.

See Developing Security Providers for Oracle WebLogic Server.

Managing WebLogic Server Security

When you manage WebLogic Server security, you focus primarily on two tasks: configuring security realms, and creating security policies.

Security Realms

A security realm comprises mechanisms for protecting WebLogic resources. Each security realm consists of a set of configured security providers, users, groups, security roles, and security policies. A user must be defined in a security realm to be able to access any WebLogic resources defined in that realm. When a user attempts to access a WebLogic resource, WebLogic Server authenticates the user, and then authorizes access by determining whether the user can be mapped to the security role that is defined in the security realm and designated in the security policy for that WebLogic resource.

Security Policies

A security policy answers the question, "Who has access to this WebLogic resource?" A security policy is an association between a WebLogic resource and one or more users, groups, or security roles that protects the WebLogic resource against unauthorized access. When creating a security policy, you can optionally define date and time constraints. A WebLogic resource has no protection until you assign it a security policy.

You assign security policies to any of the defined WebLogic resources (for example, an EJB resource or a JNDI resource) or to attributes or operations of a particular instance of a WebLogic resource (an EJB method or a servlet within a web application). If you assign a security policy to a type of WebLogic resource, all new instances of that resource inherit that security policy. Security policies assigned to individual resources or attributes override security policies assigned to a type of WebLogic resource.

Security for Coherence

Three key security features are available for use when you deploy Oracle Coherence within an Oracle WebLogic Server domain: Oracle Coherence access controllers, Oracle WebLogic Server authorization, and Oracle Coherence identity tokens.

Coherence is secured using both WebLogic Server security components and Coherence-specific security components. The components include:

  • SSL for authentication between Coherence cluster members

  • SSL for authentication between extend clients (external to WebLogic Server) and a Coherence cluster

  • WebLogic Server policies and roles for authorizing Coherence services and caches

  • Identity assertion between extend clients and Coherence clusters

For details about configuring Coherence security, see Securing Coherence in WebLogic Server in the Securing Oracle Coherence.

Roadmap for Securing WebLogic Server

The WebLogic Server documentation set includes several introductory, procedural, and reference topics, including examples, that help you understand how to use the WebLogic Security Service.

Table 10-1 Roadmap for Securing WebLogic Server

Major Task Subtasks and Additional Information

Learning more about fundamental security concepts

Administering WebLogic Server security

Authenticating users

Configuring SSL

Configuring authorization

Learning more about security realms

Programming applications for security

Guidelines for locking down your WebLogic Server production environment