Putting It All Together Some EJB™ Design Issues and J2EE Security

1

Agenda
• Improve performance with • Security basics
– Object granularity – Session beans

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

2

Use Course Grained Objects
get set get set

entity

getXxDetails

entity
setXxDetails

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

Even if Network Communication is transparent using RMI, don’t forget there can be a performance cost if there are too many remote method calls. provide bulk-CRUD (Create, Read, Update, and Delete) API to access Entity Object values. If Remote clients do lots get,set for every attribute, could create network performance problems

• •

3

Use Session Beans for Controlling Process Flow
withdraw deposit client server
Account entity Account entity

transfer
withdraw

Account entity Account entity

Atm session
deposit

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

Having a session bean controlling process flow eases the load on the system. By keeping the overall transaction short and local to the server, it reduces the possibility of other threads locked up due to contention. Session beans should be used to interact with entity beans. Clients should do most of their work with coarse grained session components and limited direct interaction with entity beans.

4

J2EE™ APM

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

The Advantage of J2EE™ is that the application model encapsulates the layers of functionality in specific types of components. Business logic is encapsulated in Enterprise JavaBeans (EJB™ ) components. And client interaction can be presented through plain HTML web pages, through web pages powered by Java applets, Java Servlets API, or JavaServer Pages technology, or through stand-alone Java applications. Components communicate transparently using various standards: HTML, XML, HTTP, SSL, RMI, IIOP, and others. Reusable J2EE™ components mean competitive choices for enterprise developers and IT organizations. J2EE™ will enable them to assemble applications from a combination of standard, commercially available components and their own custom components. From general business application components to vertical market solutions, a range of standardized Java 2 Enterprise Edition functionality is expected to be available off the shelf. This means that an e-commerce site could be built using a combination of off-the-shelf EJB™ components for shopping cart behaviors, modified EJB™ components for specialized customer services, and completely customized layouts using JavaServer Pages technology that bring a unique look and feel to the site. This approach means faster development time, better quality and maintainability, and portability across a range of enterprise platforms. The bottom line benefits are increased programmer productivity, better strategic use of computing resources, and greater return on an organization's technology investments.

5

Thin Client MVC Application Design Model
Entity Session JSP Entity DB

servlet

JSP: Servlet: Session: Presentation Control Business Process Layout Glue between
UI And Server

Entity: Business Data

Business Logic
© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

•View - The UI view involves the presentation layout (the actual HTML output), for the results of the interaction. For HTML clients, this can be done using JSP. •Controller- presentation logic (the logical connection between the user and EJB™services), necessary to process the HTTP request, control the business logic, and select an appropriate response. This can be provided by Java Servlets or Session Beans. •Business logic (model) -the business logic (the core business transactions and processing), necessary to accomplish the goal of the interaction (calculations, queries, and/or updates to a database, etc). Business logic should be separated from UI logic. This makes it possible to have different clients (for example browser and GUI) using the same beans. Separating the 2 also makes the business components easier to re-use, maintain, and update or change. •Session Beans represent the business process part of Business Logic. Session Beans manage information relating to a conversation between the client and the server. •Entity Beans represent the business data (stored in data base) part of Business Logic. Entity beans represent and manipulate persistent application domain data.

6

MVC Continued
• Intent from the JSP 0.92 Spec:
– Model 1:

– Model 2:

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

7

Servlet calling EJB™and passing results to JSP
import javax.servlet.*; import javax.servlet.http.*; public class ShoppingServlet extends HttpServlet { public void doPost (HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { HttpSession session = req.getSession(false); Context initial = new InitialContext(); Object objref = initial.lookup(jndiName); customerHome =(CustomerHome)PortableRemoteObject.narrow (objref, CustomerHome.class); customerRef = customerHome.findByPrimaryKey (email); cd = customerRef.getCustomerDetails(); session.putValue(“customer", cd ); String url="/jsp/EBookStore.jsp"; ServletContext sc = getServletContext(); RequestDispatcher rd = sc.getRequestDispatcher(url); rd.forward(req, res); }
© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

8

JSP displays results
<%@ page session="true" import="java.util.*" %> <html> <head> <title>Online Bookstore</title> </head> <body bgcolor="#33CCFF"> <table> <% CustomerDetails cd = = (CustomerDetails) session.getValue(“customer"); %> <tr> <td><b><%= cd.getName() %></b></td> </tr> </table> </body> </html>
© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

9

EJB™ Security
• Authentication • Authorization:

– Declarative – Programmatic or Explicit

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

10

Authentication Example
Form credential Authentication data
(userid & password, certificate)

Web Server Verifies Identity

(Authentication is Server specific. )
© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

The web client requests a URL. If client has not yet authenticated itself, the web server detects this and invokes the appropriate authentication mechanism for this resource. For example the web server could send a form that the web client uses to collect authentication data (e.g., username and password) from the user. The web client sends the authentication data to the web server, where it is validated by the web server. This validation mechanism could be local to the server, or it could leverage the underlying security services like LDAP. The web server then sets a credential for the user. Authentication is Server/Container specific. The standard way to do this is using an LDAP directory.

11

Authentication in Web Server
Authentication Trust Credential Mapping
EJB

HTTP Client

Servlet/JSP
Web Container

EJB EJB EJB Container

EIS

Initiator

Intermediate

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

12

HTTP Form Authentication Method Configuration
<user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> <login-config> <auth-method>FORM</auth-method> Authentication<form-login-page>/estore/login.jsp</form-login-page> <form-error-page>/estore/error.html</form-error-page> <login-config>

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

13

Authorization Example
Access resource
(ie update employee Record)

credential Is authorized Or Is Not Authorized Web/App Server Verifies Permission
© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

Once the client is authenticated, it must have permissions to perform restricted operations. The server determines if the user whose identity is captured in the credential is authorized to access the resource. The web server performs the authorization decision by consulting the security policy derived from the deployment descriptor associated with the resource to determine the security roles that are permitted access to the resource. The container then tests the user’s credentials against each role to determine if it can map the user to the role. The evaluation stops with an “is authorized” outcome on the first role that the web container is able to map the user to. A “not authorized” outcome is reached if the container is unable to map the user to any of the permitted roles.

14

Permissions on the J2EE Platform
•Resource protection by web container –Protection indicated by authorization-constraint –Authorization-constraint imposes authentication
as prerequisite for permission evaluation •Lazy authentication

•Resource protection by EJB container –Protection indicated by method-permission

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

15

Web Authorization Constraint
<security-constraint> <web-resource-collection> <web-resource-name>CheckOut</web-resource-name> <url-pattern>CheckOut</url-pattern> <http-method>POST</http-method> <http-method>GET</http-method> </web-resource-collection> Authorization <auth-constraint> <role-name>customer</role-name> </auth-constraint> </security-constraint>

{

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

16

Web Authorization and Authentication
<security-constraint> <web-resource-collection> <web-resource-name>checkout</web-resource-name> <url-pattern>CheckOut</url-pattern> <http-method>POST</http-method> <http-method>GET</http-method> </web-resource-collection> Authorization <auth-constraint> <role-name>customer</role-name> </auth-constraint> </security-constraint>

{

<login-config> <auth-method>FORM</auth-method> Authentication <form-login-page>/estore/login.jsp</form-login-page> <form-error-page>/estore/error.html</form-error-page> <login-config>

{

<user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> © Copyright 2000 Sun </user-data-constraint> Microsystems, Inc., All rights reserved.

17

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

18

Web Authorization constraint

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

19

Login Form
• Form-based login
– Login.jsp identified in deployment descriptor contains:
<form method="POST" action="j_security_check"> <input type="text" name="J_USERNAME"> <input type="password" name="J_PASSWORD"> </form>

– This form must be in the web .war

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

20

Form-based Login in Detail
Request Response Page Login Form Error Page

1 2

7

4
Login.jsp

5
j_security_check

9
Error.html

Protected Resource

3
1. Request made by client 2. Is client authenticated? 3. Unauthenticated client redirected 4. Login form returned to client 5. Client submits login form

6

8

6. Login succeeded, redirected to resource 7. Permission tested, result returned 8. Login failed, redirect to error page 9. Error page returned to client

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

21

EJB Authorization
• Declarative:

• Programmatic:

– Method permissions and security roles declared in deployment descriptor, container performs authorization checks. – Bean provider uses EJBContext isCallerInRole() to check permissions and and getCallerPrincipal() to check identity .

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

22

Application Assembler Defines Security Roles
§what types of users will access the bean? For example, an Account bean might be accessed by customers, bank tellers, and branch managers. Each of these user categories is called a role.
<assembly-descriptor> <security-role> <description>May deposit/withdraw from account</description> <role-name>Customer</role-name> </security-role> <security-role> <description>may create/delete accounts</description> <role-name>BankTeller</role-name> </security-role>
© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

The Application Assembler can define one or more security roles in the deployment descriptor. The Application Assembler then assigns groups of methods of the enterprise beans’ home and remote inter-faces to the security roles to define the security view of the application. Because the Application Assembler does not, in general, know the security environment of the operational environment, the security roles are meant to be logical roles (or actors), each representing a type of user that should have the same access rights to the application. The Deployer then assigns user groups and/or user accounts defined in the operational environment to the security roles defined by the Application Assembler. Defining the security roles in the deployment descriptor is optional for the Application Assembler. Their omission in the deployment descriptor means that the Application Assembler chose not to pass any security deployment related instructions to the Deployer in the deployment descriptor.

23

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

24

Application Assemblers Specify Method Permissions
§Method permissions indicate which roles are allowed to invoke which methods.
<method-permission>
<role-name>Customer</role-name> <method> <ejb-name>Account</ejb-name> <method-name>debit</method-name> </method> </method-permission> <method-permission> <role-name>BankTeller</role-name> <method> <ejb-name>Account</ejb-name> <method-name>create</method-name> </method> </method-permission>
© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

If the Application Assembler has defined security roles for the enterprise beans in the ejb-jar file, he or she can also specify the methods of the remote and home interface that each security role is allowed to invoke. Method permissions are defined in the deployment descriptor as a binary relation from the set of security roles to the set of methods of the home and remote interfaces of the enterprise beans, including all their superinterfaces (including the methods of the EJBHome and EJBObject interfaces). The method permissions relation includes the pair (R, M) if and only if the security role R is allowed to invoke the method M. The Application Assembler defines the method permissions relation in the deployment descriptor using the method-permission elements as follows. • Each method-permission element includes a list of one or more security roles and a list of one or more methods. All the listed security roles are allowed to invoke all the listed methods. Each security role in the list is identified by the role-name element, and each method (or a set of methods, as described below) is identified by the method element. An optional description can be associated with a method-permission element using the description element. • The method permissions relation is defined as the union of all the method permissions defined in the individual method-permission elements. • A security role or a method may appear in multiple method-permission elements. It is possible that some methods are not assigned to any security roles. This means that none of the security roles defined by the Application Assembler needs access to the methods.

25

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

26

Deployer Map Roles to Users/groups
•map the roles to the actual users (or groups) of the operating environment <rolemapping> <role name="Branchmanager"> <principals><principal> <name>scott</name> </principal> </principals> <groups> <group name="mgr"/> </groups> </role> </rolemapping>
© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

The Deployer uses deployment tools provided by the EJB™Container Provider to read the security view of the application supplied by the Application Assembler in the deployment descriptor. The Deployer’s job is to map the security view that was specified by the Application Assembler to the mechanisms and policies used by the security domain in the target operational environment. The output of the Deployer’s work includes an application security policy descriptor that is specific to the operational environment. The format of this descriptor and the information stored in the descriptor are specific to the EJB™Container. Assignment of security roles The Deployer assigns principals and/or groups of principals (such as individual users or user groups) used for managing security in the operational environment to the security roles defined in the security-role elements of the deployment descriptor. The EJB™architecture does not specify how an enterprise should implement its security architecture. Therefore, the process of assigning the logical security roles defined in the application’s deployment descriptor to the operational environment’s security concepts is specific to that operational environment. Typically, the deployment process consists of assigning to each security role one or more user groups (or individual users) defined in the operational environment. This assignment is done on a per-application basis. (That is, if multiple independent ejb-jar files use the same security role name, each may be assigned differently.)

27

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

28

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

In this scenario, Mary transfers money between her savings and checking accounts from her Web browser. To transfer the funds, Mary enters a URL that accesses a JSP component. This component calls a JavaBeansTM component, which invokes the transfer method of the Account enterprise bean. The J2EE administrator enforces security with these rules: • • • • The JSP component is a protected resource. Only the Customer role may invoke the transfer method of the Account enterprise bean. The J2EE group named CurrentCustomer belongs to the Customer role. Mary's J2EE user belongs to the CurrentCustomer group in the default realm.

When Mary transfers the funds, the J2EE server enforces security as follows: 1. 2. 3. 4. 5. 6. 7. 8. Mary's browser attempts to access the JSP component. Because the component is a protected resource, authentication is required. The Web service requests the Web browser to prompt for the J2EE user name and password. Mary enters her J2EE user name and password, which are passed back to the J2EE server. The authentication service verifies that the user name and password exist in the default realm. The Web browser is allowed to access the JSP component. Mary clicks the Transfer button on the form generated by the JSP component, which calls a JavaBeans component. The JavaBeans component attempts to invoke the transfer method of the Account enterprise bean. Mary's J2EE group (CurrentCustomer) belongs to the Customer role, which is allowed to invoke the transfer method. Therefore, the EJB container authorizes the invocation.

29

Programmatic Security
• For more complex security checks, use programmatic APIs • Servlets - HttpServletRequest interface has getRemoteUser, getUserPrincipal and isUserInRole methods • EJBs - getCallerPrincipal and isCallerInRole in EJBContext

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

30

Resources
• O'REILLY: Enterprise JavaBeans By Richard Monson-Haefel • Wiley: Mastering Enterprise JavaBeans By Ed Roman • Govind Seshadri www.Jguru.com www.javaworld.com • J2EE specification, Servlet Specification, Blueprints

© Copyright 2000 Sun Microsystems, Inc., All rights reserved.

31

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer: Get 4 months of Scribd and The New York Times for just $1.87 per week!

Master Your Semester with a Special Offer from Scribd & The New York Times