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.
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
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.
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.
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
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.xmldeployment descriptor file in the application's WAR or EAR file, as specified by the CDI specification (
metadata-completeattribute in the
web.xmlfile for the web applications must NOT be set to
true. The default in WebLogic Server is
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-assignmentelement in the
weblogic.xmldeployment 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.