Book Image

Java EE 8 Cookbook

By : Elder Moraes
Book Image

Java EE 8 Cookbook

By: Elder Moraes

Overview of this book

Java EE is a collection of technologies and APIs to support Enterprise Application development. The choice of what to use and when can be dauntingly complex for any developer. This book will help you master this. Packed with easy to follow recipes, this is your guide to becoming productive with Java EE 8. You will begin by seeing the latest features of Java EE 8, including major Java EE 8 APIs and specifications such as JSF 2.3, and CDI 2.0, and what they mean for you. You will use the new features of Java EE 8 to implement web-based services for your client applications. You will then learn to process the Model and Streaming APIs using JSON-P and JSON-B and will learn to use the Java Lambdas support offered in JSON-P. There are more recipes to fine-tune your RESTful development, and you will learn about the Reactive enhancements offered by the JAX-RS 2.1 specification. Later on, you will learn about the role of multithreading in your enterprise applications and how to integrate them for transaction handling. This is followed by implementing microservices with Java EE and the advancements made by Java EE for cloud computing. The final set of recipes shows you how take advantage of the latest security features and authenticate your enterprise application. At the end of the book, the Appendix shows you how knowledge sharing can change your career and your life.
Table of Contents (14 chapters)

Running your first Security API code

Security is one of the top concerns when you build an enterprise application. Luckily, the Java EE platform now has this API that handles many of the enterprise requirements in a standardized way.

In this recipe, you will learn how to define roles and give them the right authorization based on rules defined in the methods that manage sensitive data.

Getting ready

We start by adding our dependencies to the project:

        <dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.apache.tomee</groupId>
<artifactId>openejb-core</artifactId>
<version>7.0.4</version>
</dependency>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>8.0</version>
<scope>provided</scope>
</dependency>

How to do it...

  1. We first create a User entity:
@Entity 
public class User implements Serializable{

@Id
private Long id;
private String name;
private String email;

public User(){
}

public User(Long id, String name, String email) {
this.id = id;
this.name = name;
this.email = email;
}

//DON'T FORGET THE GETTERS AND SETTERS
//THIS RECIPE WON'T WORK WITHOUT THEM
}
  1. Here, we create a class to store our security roles:
public class Roles {
public static final String ADMIN = "ADMIN";
public static final String OPERATOR = "OPERATOR";
}
  1. Then, we create a stateful bean to manage our user operations:
@Stateful
public class UserBean {

@PersistenceContext(unitName = "ch01-security-pu",
type = PersistenceContextType.EXTENDED)
private EntityManager em;

@RolesAllowed({Roles.ADMIN, Roles.OPERATOR})
public void add(User user){
em.persist(user);
}

@RolesAllowed({Roles.ADMIN})
public void remove(User user){
em.remove(user);
}

@RolesAllowed({Roles.ADMIN})
public void update(User user){
em.merge(user);
}

@PermitAll
public List<User> get(){
Query q = em.createQuery("SELECT u FROM User as u ");
return q.getResultList();
}
  1. Now, we need to create an executor for each role:
public class RoleExecutor {

public interface Executable {
void execute() throws Exception;
}

@Stateless
@RunAs(Roles.ADMIN)
public static class AdminExecutor {
public void run(Executable executable) throws Exception {
executable.execute();
}
}

@Stateless
@RunAs(Roles.OPERATOR)
public static class OperatorExecutor {
public void run(Executable executable) throws Exception {
executable.execute();
}
}
}
  1. And finally, we create a test class to try our security rules.

Our code uses three test methods: asAdmin(), asOperator(), and asAnonymous().

  1. First, it tests asAdmin():
    //Lot of setup code before this point

@Test
public void asAdmin() throws Exception {
adminExecutor.run(() -> {
userBean.add(new User(1L, "user1", "[email protected]"));
userBean.add(new User(2L, "user2", "[email protected]"));
userBean.add(new User(3L, "user3", "[email protected]"));
userBean.add(new User(4L, "user4", "[email protected]"));

List<User> list = userBean.get();

list.forEach((user) -> {
userBean.remove(user);
});

Assert.assertEquals("userBean.get()", 0,
userBean.get().size());
});
}
  1. Then it tests asOperator():
    @Test
public void asOperator() throws Exception {

operatorExecutor.run(() -> {
userBean.add(new User(1L, "user1", "[email protected]"));
userBean.add(new User(2L, "user2", "[email protected]"));
userBean.add(new User(3L, "user3", "[email protected]"));
userBean.add(new User(4L, "user4", "[email protected]"));

List<User> list = userBean.get();

list.forEach((user) -> {
try {
userBean.remove(user);
Assert.fail("Operator was able to remove user " +
user.getName());
} catch (EJBAccessException e) {
}
});
Assert.assertEquals("userBean.get()", 4,
userBean.get().size());
});
}
  1. And, finally it tests asAnonymous():
    @Test
public void asAnonymous() {

try {
userBean.add(new User(1L, "elder",
"[email protected]"));
Assert.fail("Anonymous user should not add users");
} catch (EJBAccessException e) {
}

try {
userBean.remove(new User(1L, "elder",
"[email protected]"));
Assert.fail("Anonymous user should not remove users");
} catch (EJBAccessException e) {
}

try {
userBean.get();
} catch (EJBAccessException e) {
Assert.fail("Everyone can list users");
}
}
This class is huge! For the full source code, check the link at the end of the recipe.

How it works...

The whole point in this recipe is to do with the @RolesAllowed, @RunsAs, and @PermitAll annotations. They define what operations each role can do and what happens when a user tries an operation using the wrong role.

There's more...

What we did here is called programmatic security; that is, we defined the security rules and roles through our code (the program). There's another approach called declarative security, where you declare the rules and roles through application and server configurations.

One good step up for this recipe is if you evolve the roles management to a source outside the application, such as a database or a service.

See also