1. Transactions and Security

2. Contents  Transactions  Transaction Support in EJB  Security  Security Support in EJB

3. 1. Transactions A transaction is used to ensure that the data is kept in a consistent state. It represents a logical group of operations that must be performed as a single unit, also known as a unit of work.  Every operation must succeed in order for the transaction to succeed (we say that the transaction is committed).  If one of the operations fails, the transaction fails as well (the transaction is rolled back).  Transactions must guarantee a degree of reliability and robustness and follow the ACID properties.

4. 1. Transactions  ACID  Local Transactions  XA and Distributed Transactions

5. 1.1.ACID ACID refers to the four properties that define a reliable transaction: Atomicity, Consistency, Isolation, and Durability

6. Transferring money from one account to the other:  Atomicity: The savings account is debited using a SQL update statement, the current account is credited using a different update statement. These operations have to be done in the same unit of work because you don’t want the debit to occur but not the credit.  Isolation: From the perspective of an external application querying the accounts, only when both operations have been successfully performed are they visible.

7.  Consistency: Transaction operations (either with a commit or a rollback) are done within the constraints of the database (such as primary keys, relationships, or fields).  Durability: Once the transfer is completed, the data can be accessed from other applications.

8. 1.2.Local Transactions A transaction using a single resource is called a local transaction. There is only one transactional resource.  An application performs several changes to a single resource (e.g., a database).  The application interacting with a resource through a transaction manager and a resource manager

9.  The transaction manager is the core component responsible for managing the transactional operations. It creates the transactions on the behalf of the application, informs the resource manager that it is participating in a transaction (an operation known as enlistment), and conducts the commit or rollback on the resource manager.  The resource manager is responsible for managing resources and registering them with the transaction manager. An example of a resource manager is a driver for a relational database, a JMS resource, or a Java connector.  The resource is persistent storage from which you read or write (a database, a message destination, etc.).

10. 1.3.XA and Distributed Transactions Many enterprise applications use more than one resource.  Returning to the example of the fund transfer, the savings account and the current account could be in separate databases. You would then need transaction management across several resources, or resources that are distributed across the network. Such enterprise-wide transactions require special coordination involving XA and Java Transaction Service (JTS).

11. An XA transaction involving two resources

12. To have a reliable transaction across several resources, the transaction manager needs to use an XA resource manager interface.  XA is a standard specified by the Open Group (http://www.opengroup.org) for distributed transaction processing (DTP) that preserves the ACID properties.  It is supported by JTA and allows heterogeneous resource managers from different vendors to interoperate through a common interface.

13. XA uses a two-phase commit (2pc) to ensure that all resources either commit or roll back any particular transaction simultaneously.  During phase 1, each resource manager is notified through a “prepare” command that a commit is about to be issued. This allows the resource managers to declare whether they can apply their changes or not. If they all indicate that they are prepared, the transaction is allowed to proceed, and all resource managers are asked to commit in the second phase.

14. Two-phase commit

15. Resources may be distributed across the network.  Such a system relies on JTS. JTS implements the Object Management Group (OMG) Object Transaction Service (OTS) specification, allowing transaction managers to participate in distributed transactions through Internet Inter-ORB Protocol (IIOP).  As an EJB developer, you don’t have to worry about this; just use JTA, which interfaces with JTS at a higher-level.

16. 2. Transaction Support in EJB When you develop business logic with EJBs, you don’t have to worry about the internal structure of transaction managers or resource managers because JTA abstracts most of the underlying complexity.  An EJB container is a transaction manager that supports JTA as well as JTS to participate in distributed transactions involving other EJB containers.  In fact, transactions are natural to EJBs, and by default each method is automatically wrapped in a transaction.

17.  Container-Managed Transactions  Bean-Managed Transactions

18. 2.1.Container-Managed Transactions (CMT) The EJB container provides transaction management services to session beans and MDBs A Stateless Bean with CMT

19. The container handles the transaction

20. CMT Attributes REQUIRED  This attribute, the default value, means that a method must always be invoked within a transaction.  The container creates a new transaction if the method is invoked from a nontransactional client. If the client has a transaction context, the business method runs within the client’s transaction.  Use REQUIRED if you modify any data and you don’t know whether the client has started a transaction or not.

21. REQUIRES_NEW  The container always creates a new transaction before executing a method, regardless of whether the client is executed within a transaction.  If the client is running within a transaction, the container suspends that transaction temporarily, creates a second one, commits it, and then resumes the first transaction. This means that the success or failure of the second transaction has no effect on the existing client transaction.  You should use REQUIRES_NEW when you don’t want a rollback to affect the client.

22. SUPPORTS  The EJB method inherits the client’s transaction context. If a transaction context is available, it is used by the method; if not, the container invokes the method with no transaction context.  You should use SUPPORTS when you have read- only access to the database table.

23. MANDATORY  The container requires a transaction before invoking the business method but should not create a new one.  If the client has a transaction context, it is propagated; if not, a javax.ejb.EJBTransactionRequiredException is thrown.

24. NOT_SUPPORTED  The EJB method cannot be invoked in a transaction context. If the client has no transaction context, nothing happens; if it does, the container suspends the client’s transaction, invokes the method, and then resumes the transaction when the method returns. NEVER  The EJB method must not be invoked from a transactional client. If the client is running within a transaction context, the container throws a javax.ejb.EJBException.

25. Two calls made to InventoryEJB with different transaction policies

27. Marking a CMT for Rollback Sometimes, you might want to prevent the transaction from being committed if some error or business condition is encountered. It is important to stress that a CMT bean is not allowed to roll back the transaction explicitly.  To use the EJB context to inform the container to roll back.  Or to inform the container to roll back by throwing specific types of exceptions.

28. @Stateless public class ABean { @PersistenceContext(unitName = "PU") private EntityManager em; @Resource private SessionContext ctx; public void aMethod() { … //do something if (Some error is encountered) ctx.setRollbackOnly(); } The container will do the actual rollback when it is time to end the transaction

29. To inform the container to roll back by throwing specific types of exceptions  Throwing an exception in a business method will not always mark the transaction for rollback.  It depends on the type of exception or the metadata defining the exception.

32. 2.2.Bean-Managed Transactions EJBs offer a programmatic way to manage transaction demarcations with BMT. BMT allows you to explicitly manage transaction boundaries (begin, commit, rollback) using JTA.  With the BMT, you manually define transaction boundaries inside the method itself. First of all, we get a reference of the UserTransaction using injection through the @Resource annotation. The method begins the transaction, does some business processing, and then, depending on some business logic, commits or rolls back the transaction.

33. Methods of the javax.transaction.UserTransaction Interface

35. 3. Security Principals and Roles  A principal represents a user who has been authenticated by an authentication system (e.g., by verifying a username and password in the database).  You can then organize principals into groups, known as roles, allowing principals to share a common set of permissions  A user, once authenticated, is bound to a principal. The principal has a unique identifier and can be linked to several roles.

37. Authentication and Authorization  Authentication is the process of verifying the user’s identity (user ID and password, OpenID, fingerprint check, and so on) against an authentication system, and assigning a principal to the user.  Authorization is the process of determining whether a principal (an authenticated user) has access to a particular resource (e.g., a book) or a function (e.g., removing a book). Depending on his role, the user can have access to all resources, none, or a subset.

39. 4. Security Support in EJB The primary purpose of the EJB security model is to control access to business code. Authentication is handled by the web tier (or a client application), the principal and its roles are then passed to the EJB tier, and the EJB checks whether the authenticated user is allowed to access a method based on its role.

40. Declarative Security The declarative security policy can be defined in the bean using annotations or in the XML deployment descriptor. Declarative authorization involves declaring roles, assigning permission to methods (or to the entire bean), or changing temporarily a security identity. These controls are made by the annotations. Each annotation can be used on the bean and/or on the method.

43. The InventoryEJB.addItem() method will be invoked with an inventoryDpt role.

44. Programmatic Security The SessionContext interface:  isCallerInRole() : This method returns a boolean and tests whether the caller has a given security role.  getCallerPrincipal() : This method returns the java.security.Principal that identifies the caller.

47. Form-Based Authentication with a JavaServer Faces Application This example explains how to use form-based authentication with a JavaServer Faces application.  With form-based authentication, you can customize the login screen and error pages that are presented to the web client for authentication of the user name and password.  When a user submits his or her name and password, the server determines whether the user name and password are those of an authorized user and, if authorized, sends the requested web resource.

48. Configuring a user database that the application can use for authenticating users  File Realm Flat files for development time or for small applications  JBDC Realm Relational databases for applications of all sizes ...

51. Set up Default Principal to Role Mapping on the GlassFish Server

52. Look at the keyfile  domains\domain1\config\keyfile

53. Create a Java Web Application

57. Creating the Login Form and the Error Page  Create a folder in the web folder to store Login Form and Error pages

62. Specifying Security for the Form-Based Authentication Example  Edit the file web/WEB-INF/web.xml Specify form-based instead of basic authentication for a JavaServer Faces example Add the security elements to the deployment descriptor

64. Create a JSF Managed Bean

69. The JDBC realm The JDBC realm is one of the most common realms in the production environment. Basically, the JDBC realm allows us to use a set of tables containing usernames, passwords, and user's group membership as an authentication source.

70. Create the required tables and populate them with some sample data  Tables USERS  username VARCHAR(255) not null  password VARCHAR(255) null GROUPS  groupname VARCHAR(255) null  username VARCHAR(255) null  Add users, group insert into users values('xuanpd','12345678'); insert into groups values('TutorialUser','xuanpd');

72. To connect to the connection pool with database of users, groups tables

74. Edit the login config in the file web/WEB- INF/web.xml to use JDBC Realm

75. Reference Antonio Goncalves, Beginning Java EE 6 Platform with GlassFish 3, Chapter 9, Apress 2009