1. DEVELOPING ENTERPRISE APPLICATIONS USING EJB
SECURITY

2. CONTENTS Applications Security Concepts J2EE Security Architecture
Authorization in J2EE Architecture
Mechanism of Caller Authentication
Security Responsibilities in J2EE platform
Workshops
Exercises

3. APPLICATION SECURITY CONCEPTS
Security mechanisms must be implemented in almost all enterprise applications to
An enterprise application contains multiple resources, that send sensitive information over unprotected networks, can be accessed by many users
Authentication
Ensures that the identity of the client is true
Enables identification of the user interacting with an application
Is a process by which one entity in an interaction determines the identity of the other
Ensure that it is interacting with the correct server
The most common form of authentication involves the use of username and password (encrypting and transmitting)
The use of digital certificates offers a stronger form of authentication. Digital certificates can be used to identity end-users, servers, and other software components
Authorization
After the completion of authentication, permissions have to granted to the user to perform all desired operations. (Grant permissions to the correct user)
Controls what the authenticated user is allowed to do after they get into the application
Access control: phan quyen su dung

4. APPLICATION SECURITY CONCEPTS
Database
containing
usernames and
passwords
Security
identity
The security identity lasts till the client is connected
User
Authentication
General User
Logging In
Authentication
Well-defined security Role

5. ACCESS CONTROL LISTS (ACLs)
Permissions represent a right to access a particular resource or to perform some action on an application.
An administrator usually protects resources by creating lists of users and groups that have the permission to access a particular resource.
These lists are referred as access control lists (ACLs)
An ACL file is made up of entries, which contain a set of permissions for a particular resource and a set of users who can access those resources
Data
Robust: thiet thuc, manh me, chac chan
Temper: ep lai, co lai – giam tinh nang
User
Access control Lists
Business objects
Sub systems

6. J2EE SECURITY ARCHITECTURE
Is based on authorization model, as it is concerned with granting or denial of access to clients that have already been authenticated by the container.
Enables the application developer to concentrate on the needs of the application and leave the technicalities of security and authentication on to the administrator.
Realms
The authentication and authorization information and the enforcement policies, as defined by an administrator.
Are typically repositories containing users, groups, permissions, and secured resources.
Contains the usernames and passwords and the authentication and authorization policy details that control these users.
Can be stored in an XML file, a text file, and sometimes even in a database
Interprocess: lien tien trinh
Intraprocess: noi xu ly

7. J2EE SECURITY ARCHITECTURE (cont)
Users and Principals
J2EE security architecture does not deal with user identities directly.
Principal
Abstract user identities.
Is an entity that can be authenticated by the system.
Is typically an end user or any other service requesting access to the application.
Is identified by a name; often the username is also the principal for that end user.
Groups and Roles
Groups
Are used primarily to manage multiple users in an efficient manner.
When a group is given some access rights and permissions, all members of the group gain this permission indirectly.
Roles
Are abstract forms of group.
Are the particular way that a user may interact with an application
Defines the access rights that the user must have to perform this interaction. Each role contains a particular set of permissions.

8. J2EE SECURITY ARCHITECTURE (cont)
Role References
Is a level of abstraction which is used when the EJBs from different sources are combined together in an application.
In the EJB’s deployment descriptor, the bean provider can assign both role and role reference to the various methods of a bean class. When the beans are combined in an application, the application assembler may want to change the role name. With the help of role references, the application assembler can easily change the role names without having any effect on the code anywhere.
Managing Users
Users, groups, and roles are managed by the application server.
An application prompts a user for their username and password before allowing them to access a protected resource. Then, that information is passed to the server.
The server either authenticates the user and sends the protected resource, or does not authenticate the user
Setting Up Security Roles
For enterprise applications, security roles are defined in the application.xml.
For individually EJB modules, roles are defined in ejb-jar.xml
For Web application, the security roles are defines in web.xml.
Feasible: thuan tien, tien loi

9. J2EE SECURITY ARCHITECTURE (cont)
Mapping Roles to Users and Groups
The role assigned to the user in the application must be mapped to the users and groups defined on the application server.
During the deployment,
The security architecture provides a mechanism for mapping the roles defined in the application to the users or groups defined in the runtime realm.
To map a role name permitted by the application or module to users and groups defined in the server, the security-role-mapping element is used in the vendor-specific deployment descriptors.
Spawn: de trung, tao ra

10. MECHANISM OF CALLER AUTHENTICATION
EJB-Tier Authentication
The J2EE do not contain any details about authentication at the EJB container-level.
The EJB container can protect access to the EJBs by entrusting the user identification and authentication activities to the Web container.
EJBs can be protected by Web components irrespective of whether the Web components are themselves protected or unprotected.
The Web tier may allow users who are not currently authenticated to browse the unprotected Web resources. But as soon as the user makes a request for a protected EJB resource, the user is blocked. If the Web resource is itself protected, then the user authentication is combined for both the Web and EJB resources.
EJB-tier Authorization
Authorization decisions in EJBs are taken on the basis of the client’s identity.
All calls to all EJBs from a single application within a single J2EE product, the user name returned by the EJBContext must be the same as that returned by the first in the call chain.
If the first EJB in the call chain is called by a servlet or JSP, the user name must be the same as that returned by the HttpServletRequest interface’s getUserPrincipal() method in the calling servlet or JSP page. This user must be the user used in authorization decisions for access to all EJBs in the call chain.

11. MECHANISM OF CALLER AUTHENTICATION
EJB-tier Authorization
Propagated Security Context
EJB-tier authorization is carried out on the basis of the current security context that is cached data that contains security details (username, password & authorization ...)
In the EJB call chain, the default security context propagation is called propagated which enables the propagation of the default or the actual security context of the client.
The propagated security context is specified using the <user-caller-identity> element in the ejb-jar.xml
Declarative Security Context
Declarative propagation is used if want to hide or do not want to use the security context of the client.
An additional <run-as> element
Is used in the ejb-jar.xml when using declarative propagation.
Contains a real security role name declared using the <security-role> element. When this EJB is called, the current security context will refer to this security role rather than the security role of the client.
Propagate: lan truyền

12. AUTHORIZATION IN J2EE ARCHITECTURE
Increase portability of EJB applications across different vendors and allow the different vendors to use different security mechanism.
Allow security policies to be set by the deployer or assembler rather than by the bean provider.
The EJB and J2EE specifications describe two different methods for handling security in EJBs and in other J2EE components.
Declarative security
Programmatic security
Involves usage of security-related code in the application.
Is useful for wanting more control than offered by declarative security.
Permanent: khong ben vung

13. DECLARATIVE SECURITY
Requires setting of an application’s security structure, including security roles, access control, and authentication requirements, in the application’s deployment descriptor.
The bean developer sets the role reference for the bean using the security-role-ref element in the ejb-jar.xml file.
The declaration contains a link to a security role specified using the role-link element.
The name contained in the role-link element as well as the security role name using the role-name element of security-role
If you set the security-role elements in the deployment descriptor, the business methods of the bean class must be defined with each role is authorized to invoke.
The permissions is set in the deployment descriptor using the method-permission element that can contain one or more security roles and one or more methods

14. PROGRAMMATIC SECURITY
The EJB specification does not recommend using of programmatic security in the EJBs.
This is because if later the application is deployed in other security domains with different roles, the source code must be changed to work correctly in this new environment.
The programmatic security is needed to want get more flexibility in the applications.
The programmatic security in an EJB can be used with two methods defined in the javax.ejb.EJBContext interface
public Boolean isCallerInRole (String roleName)
Enables to test whether the principal that made the call to an EJB business method is a member of the role specified in the argument.
public Principal getCallerPrincipal()
Returns the java.security.Principal object of the current caller.

15. RESPONSIBILITIES FOR SECURITY
Responsibilities of the Bean Provider
Use either programmatic or declarative method to specify the security attributes of an enterprise bean
Specify the names of the security roles in the <security-role-ref> tag of the deployment descriptor
Responsibilities of the Application Assembler
Defining the security roles, which have the permission to access the resources in an enterprise bean application
Defining the method permissions for accessing the methods in the home and the component interface of an enterprise bean
Linking the security role names in the <security-role-ref> tag to the role names specified in the <security-role> tag of the deployment descriptor
Specifying the methods that need to be authorized prior to their invocation by the container
Specifying the methods that cannot be accessed by including them in the <exclude-list> tag in the deployment descriptor

16. RESPONSIBILITIES FOR SECURITY (cont)
Responsibilities of the Deployer
Defining method permission for those methods that are neither present in the <exclude-list> tag nor associated with any security role
Matching the security attributes specified in the deployment descriptor to their corresponding security domains, where the application deploys
Responsibilities of the Product Provider
Providing deployment tools to the deployer
Throwing the exceptions, java.rmi.RemoteException and javax.ejb.EJBException
Allowing the deployer to state whether the caller identity obtained from the getCallerPrincipal() method
Responsibilities of the System Administrator
Creating a new user account.
Adding a user account to a specific group.
Removing a user account from a specific group.
Deleting user account.
Managing the security principals

17. J2EE SECURITY ARCHITECTURE
Client
Server
Authentication
EJB Client
Authentication/
Authorization
Authorization DB
Web Container
EJB Container
Servlet
Browser
EJB
JSP
Web Authentication
Security

18. SECURITY ON JBOSS
Login Module in JBoss is presented through the security domain with JNDI having following syntax
java:/jaas/<domain_name>
There are many module login in JBoss:
UserRolesLoginModule: get username, password and role from file properties in ejb package
DatabaseServerLoginModule: get username, password and role from DB.
...

19. CONFIGURING DEPLOYMENT DESCRIPTOR IN EJB
jboss.xml
<jboss>
<security-domain>java:/jaas/domain_name</security-domain>
<enterprise-beans>
....
</enterprise-beans>
</jboss>
ejb-jar.xml
<assembly-descriptor>
<security-role><role-name>role_name</role-name></security-role>
other security roles
<method-permission>
<role-name>role_name</role-name>
<method>
<ejb-name>ejb_name</ejb-name>
<method-name>method_name</method-name>
<method-params><method-param>data_type<method-param></method-param>
</method>
</method-permission>
...
</assembly-descriptor>

20. CONFIGURING DEPLOYMENT DESCRIPTOR IN WEB APPLICATION
jboss-web.xml
<jboss-web>
<security-domain>java:/jaas/domain_name</security-domain>
<ejb-local-ref>
...
</ejb-local-ref>
</jboss-web>
web.xml
<security-constraint>
<web-resource-collection>
<web-resource-name>name</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>HEAD</http-method>
<http-method>GET</http-method>
<http-method>PUT</http-method>
<http-method>POST</http-method>
<http-method>DELETE</http-method>
</web-resource-collection>
<auth-constraint> <role-name>roleName</role-name> other roles</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
<security-role>
<role-name>role_name</role-name>
</security-role>
other security roles

21. CONFIGURE LOGIN MODULE
UsersRolesLoginModule includes the properties file that include the authentication and role information locating at the ejb module (jar package)
Authentication: users.properties
Username1=password1
Username2=password2
...
Ex:
Geogre=a2345b
Guest=1234
Authorization – Roles: roles.properties
username1=role1[,role2, ...]
George=admin
guest=user,vip

22. CONFIGURE LOGIN MODULE (contt)
Configure LoginModule config file to JAAS applying the security constraints on application (*.conf).
Syntax:
name{login_module_class_name required|optional
[option] ; };
Ex:
Sec1{org.jboss.security.auth.spi.UsersRolesLoginModule required;};
Config LoginModule default of Jboss exists at JBOSS_HOME/client/auth.conf with default domain as other

23. EJB DEVELOPMENT PROCESS
Requirement: JBoss GA Application Server
Step 1: Creating a Bean as the previous lessions
Step 2: Configure the LoginModule with the properties files that are located the application client.
users.properties
roles.properties
Step 3: Modifying the security declaration on deployment descriptor
Step 4: Mapping the JNDI to beans
Step 5: Building and deploying on Application Server
Step 6: Creating the client application to consume
Step 7: Running the client to test the EJB

24. Step 1: Creating a Bean as the previous lessons
Create Entity Bean mapping with the Account table with following requirements
account(accountId varchar(10), balance int)
The business method
String getAccountId(), sell(int), buy(int), int getBalance()
create(String), findByPrimaryKey(String)
Notes: add the remote and home interface that can be referenced at client application

25. Step 1: Creating a Bean as the previous lessons (cont)
Diverging: hướng nào đó

26. Step 2: Configure the LoginModule with the properties files

27. Step 3: Modifying the security declaration on DD
Addition the ejb-jar.xml as following

28. Step 3: Modifying the security declaration on DD (cont)

29. Step 4: Mapping the JNDI to beans
Modifying the jboss.xml
Mapping jbosscmp-jdbc.xml

30. Step 6: Creating the client application to consume

31. Step 6: Creating the client application to consume (cont)
Cornerstone: important

32. Step 5: Building and deploying on Application Server Step 7: Running to test
Case 1: Executing the program with username and password with roles supervisors
Hint the information must not be existed
Case 2: Executing the program with username and password with roles traders.
Hint the accounts should have been created
Case 3: Executing the program with username and password with roles both traders and supervisors

33. Case 1

34. Case 2

35. Case 3

36. EXAMPLE FOR EJB COMBINE WEB APPLICATION SECURITY
Creating the application with two business method as
The dice(int) method – calculate the sum of dicing
The doIt() method – show the principal of the user access the web application to request the method on Bean

37. Step 1: Creating a Bean as the previous lessons
Create the EJB Enterprise Application Support Web
Create the stateless Bean with two business method as requirement

38. Step 2: Configure the LoginModule with the properties files

39. Step 3: Modifying the security declaration on DD
Addition the ejb-jar.xml as following

40. Step 4: Mapping the JNDI to beans
Modifying the jboss.xml

41. Step 6: Creating the web application to consume
index.jsp

42. Step 6: Creating the web application to consume (cont)
Configure the web.xml

43. Step 6: Creating the web application to consume (cont)
Configure the jboss-web.xml

44. Step 5: Building and Deploying Step 7: Run to test

45. Step 7: Run to Test (cont)

46. WORKSHOP ACTIVITIES
Building the EJB with applying security on Java Sun Application Server

47. EXERCISES
Do it again all of demos, workshops, and the following exercises on JBoss Server
Applying whole of the beans that are building in the previous lesson with security