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:
- Authentication: Authentication is a word that derives from the word genuine or real in Greek, according to Wikipedia. In the Java EE platform, it's the act to prove that a specific user is who he claims to be through the use of passwords, tokens, or certificates, according to what was specified as an authentication method for this server or container.
- Authorization: Authorization is very different from authentication because although you have proved who you are (through authentication), you may not have permission to do what you intend on the system and your action will mostly be denied, or not authorized.
- Subjects and principals: After a successful authentication process, the authorized user will receive an identity that is basically defined as a set of principals, which can be bound to other users or groups in the system. This set is a formal definition of a subject and will be stored and re-used every time the container needs to check the user identity and its permissions.
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.