1 / 47

DEVELOPING ENTERPRISE APPLICATIONS USING EJB

DEVELOPING ENTERPRISE APPLICATIONS USING EJB. SECURITY. CONTENTS. Applications Security Concepts J2EE Security Architecture Authorization in J2EE Architecture Mechanism of Caller Authentication Security Responsibilities in J2EE platform Workshops Exercises. APPLICATION SECURITY CONCEPTS.

yasir-hill
Download Presentation

DEVELOPING ENTERPRISE APPLICATIONS USING EJB

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

  4. APPLICATION SECURITY CONCEPTS Database containing usernames and passwords Security identity The security identity lasts till the client is connected User Authentication General User Authentication Logging In 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 Access control Lists User Business objects Sub systems

  6. J2EE SECURITY ARCHITECTURE • 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

  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.

  9. 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. J2EE SECURITY ARCHITECTURE (cont)

  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.

  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.

  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 fromDB. • ...

  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 <enterprise-beans> .... </enterprise-beans> <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 includesthe properties file that include the authentication and role informationlocating 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, ...] ... • Ex: 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 asother

  23. EJB DEVELOPMENT PROCESS • Requirement: JBoss 4.2.2 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)

  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)

  32. Step 5: Building and deploying on Application ServerStep 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 • Hint the information must not be existed

  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 DeployingStep 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

More Related