Security is one of the most important aspects of any application, so we dedicated an entire chapter to this topic; even so, it would be presumptuous to say that this chapter covers all details regarding the subject; instead, the approach will be to bring some of the most common situations of security on Java EE and describe how to implement them through Oracle WebLogic features.
We will explore the security concerns associated with the EJB and Web containers of Java EE. In this context, you can specify the security constraints basically in two ways:
It's also important to clarify some terminology and define what and how some of these terms will be used through this chapter. The most important ones are:
Other important terms used by security are data integrity, auditing, quality of service, and confidentiality. Also, some may define authentication and authorization as access control rules, and that most of the security constraints to protect data can be achieved through cryptography, hashing, and other advanced techniques.
Most of these concepts are implemented and can be applied using standard Java APIs and some specifics can depend on proprietary implementation of the Java EE container. The Java platform provides APIs for access control through the Java Authentication and Authorization Service (JAAS) and cryptography through the Java Cryptography Extension (JCE). These two APIs will be used in this chapter to implement the security requirements for our application.
These concepts are discussed in much more detail in the Java EE Tutorial's Security chapter and the Java Authentication and Authorization Service reference guide; both links can be found in the Web resources section of this chapter.
In Java, we have distinct security frameworks for Java SE and Java EE. Java SE uses policy files and JAAS, but Java EE offers declarative security through deployment descriptors such as web.xml
, ejb-jar.xml
; annotations; and transport security through HTTP Basic/Form authentication, SSL,
SAML, and others.
A key difference between both security frameworks is that, by default, the Java SE security framework doesn't propagate security context across different JVMs. This concept is almost a native requirement for secure Java EE applications, which needs to propagate security contexts, principals, and subjects across several layers, applications, or even physical machines (clusters) in order to provide high availability and failover for security concepts such as authentication or authorization.
In order to minimize such problems, the Java Authentication Service Provider Interface for Containers (JASPIC) specification extended the JAAS model, implementing message authentication mechanisms that can be integrated into containers or runtimes. However, keep in mind that the applications still have to use some proprietary descriptors or libraries to perform more complex security tasks, and this varies for each application server.