Using the Java EE Security API in WebLogic Server

44 Using the Java EE Security API in WebLogic Server

Using the Java EE Security API, you can define all of the security information directly within the application. 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.

Overview of the Java EE Security API (JSR 375)

The Java EE Security API (JSR 375) defines portable authentication mechanisms, and an access point for programmatic security using the SecurityContext interface. 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 supports the plug-in interface for authentication, HttpAuthenticationMechanism, and includes built-in support for the BASIC, FORM, and Custom FORM authentication mechanisms defined in the specification. WebLogic Server also supports the RememberMeIdentityStore interface, and built-in implementations of the IdentityStore interface (LDAP identity store and Database identity store) as well as the custom identity store.

The HttpAuthenticationMechanism interface is designed to capitalize on the strengths of existing Servlet and JASPIC authentication mechanisms. The IdentityStore interface is intended primarily for use by HttpAuthenticationMechanism implementations, but could in theory be used by other types of authentication mechanisms (such as a JASPIC ServerAuthModule). HttpAuthenticationMechanism implementations are not required to use IdentityStore — they can authenticate users in any manner they choose — but the IdentityStore interface is a useful and convenient mechanism.

The HttpAuthenticationMechanism and IdentityStore interfaces are implemented as CDI beans, therefore they are visible to the container through CDI. For information on CDI support in WebLogic Server, see Using Contexts and Dependency Injection for the Java EE Platform in Developing Applications for Oracle WebLogic Server.

The SecurityContext interface defines methods that allow an application to access security information about a caller, authenticate a caller, and authorize a caller.

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

For details about using JSR 375 in WebLogic Server, see Using the Java EE Security API in Developing Applications with the WebLogic Security Service.

Prerequisites for Using the Java EE Security API

Using the Java EE Security API mechanisms does not require any specific configuration, but you must ensure that other functionality, such as JASPIC and CDI, is enabled.

To use the Java EE Security API (JSR 375) features in WebLogic Server:

JASPIC must be enabled at the domain level to enable JSR 375 functionality. By default, JASPIC is enabled for a domain in WebLogic Server. If you disable JASPIC at the domain level, JSR 375 functionality is also disabled.
Web applications must include the beans.xml deployment descriptor file in the application's WAR or EAR file, as specified by the CDI specification (https://jcp.org/en/jsr/detail?id=365).
The metadata-complete attribute in the web.xml file for the web applications must NOT be set to true. The default in WebLogic Server is false.
There are no special logging requirements. Audit events triggered by implementations of the Java EE Security API are logged by the WebLogic Auditing Provider, if configured.
The Java EE Security API requires that group principal names are mapped to roles of the same name by default. If the security-role-assignment element in the weblogic.xml deployment descriptor does not declare a mapping between a security role and one or more principals in the WebLogic Server security realm, then the role name is used as the default principal.