10 Understanding WebLogic Server Security

This chapter introduces the WebLogic Server security service and methods for securing your WebLogic Server 12.1.3 environments.

This chapter includes the following sections:

• Java EE 6 Security Feature Support in WebLogic Server

• Overview of the WebLogic Server Security Service

• WebLogic Server Security Service Architecture

• Managing WebLogic Server Security

• Oracle Platform Security Services (OPSS)

• Security for Coherence

• Roadmap for Securing WebLogic Server

Java EE 6 Security Feature Support in WebLogic Server

WebLogic Server supports the following security features of Java EE 6:

• Java Authorization Contract for Containers (JACC) 1.4

  The JACC specification defines a contract between a Java EE application server and an authorization policy provider. All Java EE containers support this contract.

  The JACC specification defines java.security.Permission classes that satisfy the Java EE authorization model. The specification defines the binding of container access decisions to operations on instances of these permission classes. It defines the semantics of policy providers that use the new permission classes to address the authorization requirements of the Java EE platform, including the definition and use of roles.

• Java Authentication Service Provider Interface for Containers (JASPIC) 1.0

  The JASPIC specification defines a service provider interface (SPI) by which authentication providers that implement message authentication mechanisms may be integrated in client or server message-processing containers or runtimes. Authentication providers integrated through this interface operate on network messages provided to them by their calling container. The authentication providers transform outgoing messages so that the source of the message can be authenticated by the receiving container, and the recipient of the message can be authenticated by the message sender. Authentication providers authenticate incoming messages and return to their calling container the identity established as a result of the message authentication.

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 via the Web. 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. 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), and Java Authorization Contract for Containers (JACC).

• 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

This section provides a description of the architecture of the WebLogic Security Service. The architecture comprises three major components, which are discussed in the following sections:

• WebLogic Security Framework

• Single Sign-on with the WebLogic Server Security Framework

• SAML Token Profile Support in WebLogic Web Services

• The Security Service Provider Interfaces (SSPIs)

• WebLogic Security Providers

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 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. Single sign-on enables users to login 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 single sign-on (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.

For more information, see Developing Security Providers for Oracle WebLogic Server.

Managing WebLogic Server Security

This section covers the following topics:

• Security Realms

• 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 in order to access any WebLogic resources belonging to that realm. When a user attempts to access a particular WebLogic resource, WebLogic Server tries to authenticate and authorize the user by checking the security role assigned to the user in the relevant security realm and the security policy of the particular WebLogic resource.

Security Policies

Security policies replace access control lists (ACLs) and 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 one or more users, groups, or security roles. You can optionally define date and time constraints for a security policy. 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.

Oracle Platform Security Services (OPSS)

Oracle Platform Security Services (OPSS) provides enterprise product development teams, systems integrators (SIs), and independent software vendors (ISVs) with a standards-based, portable, integrated, enterprise-grade security framework for Java Standard Edition (Java SE) and Java Enterprise Edition (Java EE) applications.

OPSS provides an abstraction layer in the form of standards-based application programming interfaces (APIs) that insulates developers from security and identity management implementation details. With OPSS, developers don't need to know the details of cryptographic key management or interfaces with user repositories and other identity management infrastructures. With OPSS, in-house developed applications, third-party applications, and integrated applications all benefit from the same uniform security, identity management, and audit services across the enterprise.

OPSS is not a component of WebLogic Server and is not available in a standalone WebLogic Server installation. OPSS is available from the Oracle Fusion Middleware infrastructure software, and may be used with WebLogic Server in domains that are based upon, or extended with, the Oracle JRF template. For more information, see Installing and Configuring the Oracle Fusion Middleware Infrastructure. For information about the Oracle JRF domain template, see "Oracle JRF Template" in Domain Template Reference.

Security for Coherence

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 on configuring Coherence security, see "Securing Coherence in WebLogic Server" in the Oracle Coherence Security Guide.

Roadmap for Securing WebLogic Server

Table 10-1 Roadmap for Securing WebLogic Server

Major Task	Subtasks and Additional Information
Learning more about fundamental security concepts	Auditing Authentication Security Assertion Markup Language (SAML) Single sign-on (SSO) Authorization Identity and trust Secure Sockets Layer (SSL) WebLogic security framework Single sign-on with the WebLogic Server security framework SAML token support in WebLogic Web services Security Service Provider Interfaces (SSPIs) WebLogic security providers
Administering WebLogic Server security	Security management concepts Customizing the default security configuration Migrating security data Managing the embedded LDAP server Managing the RDBMS security store Configuring keystores Configuring SSL Configuring cross-domain security Using compatibility security Secure WebLogic resources using roles and policies Exploring security options for cluster architectures Configuring Security for Coherence
Authenticating users	Authenticating users defined in an LDAP server Authenticating against an RDBMS system Authenticating against a Windows NT domain Authenticating a remote user Using SAML Configuring Single Sign-on (SSO) Configuring single sign-on with Microsoft clients Configuring single sign-on with Web browsers and HTTP clients Using Kerberos Using multiple authentication providers Configuring password composition rules Managing users and groups Using Java Authentication SPI for Containers (JASPIC)
Configuring SSL	Setting up SSL: main steps Configuring keystores Creating a keystore: example X.509 certificate revocation checking
Configuring authorization	Securing WebLogic resources using roles and policies Configuring an authorization provider Using multiple authorization providers Using JAAS authorization Configuring a role mapping provider Using Java Authorization Contract Containers (JACC)
Learning more about security realms	Introduction to security realms Users Groups Security roles Security policies Security providers
Programming applications for security	Programming security for WebLogic Server Configuring resource adapter security WebLogic Web service security topics
Best practices	Securing a production environment