43 Using Jakarta Security in WebLogic Server
Using the Jakarta Security specification, 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 Jakarta Security
The Jakarta Security specification 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 Jakarta Authentication and Servlet 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 Jakarta Authentication 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 Jakarta 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 Jakarta Security is defined in the specification at https://jakarta.ee/specifications/security/
.
For details about using Jakarta Security in WebLogic Server, see Using Jakarta Security in Developing Applications with the WebLogic Security Service.
Prerequisites for Using Jakarta Security
Using the Jakarta Security specification mechanisms does not require any specific configuration, but you must ensure that other functionality, such as Jakarta Authentication and Jakarta Contexts and Dependency Injection (CDI), is enabled.
To use Jakarta Security features in WebLogic Server:
-
Jakarta Authentication must be enabled at the domain level to enable Jakarta Security functionality. By default, Jakarta Authentication is enabled for a domain in WebLogic Server. If you disable Jakarta Authentication at the domain level, Jakarta Security 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://jakarta.ee/specifications/cdi/
. -
The
metadata-complete
attribute in theweb.xml
file for the web applications must NOT be set totrue
. The default in WebLogic Server isfalse
. -
There are no special logging requirements. Audit events triggered by implementations of the Jakarta Security specification are logged by the WebLogic Auditing Provider, if configured.
-
The Jakarta Security specification requires that group principal names are mapped to roles of the same name by default. If the
security-role-assignment
element in theweblogic.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.