Putting It All Together

Some EJB™ Design Issues

and
J2EE Security

1
Agenda

• Improve performance with

– Object granularity
– Session beans
• Security basics

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

2
 Use Course Grained Objects

get

set entity
get
set

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
Account
entity
deposit Account
entity
client server

transfer Account
withdraw
entity
Atm
session Account
deposit
entity

© 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

servlet Entity

Session DB
JSP Entity

JSP: Servlet: Session: Entity:

Presentation Control Business Process Business Data
Layout Glue between
UI
And Business Logic
Server
© 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

Servlet/JSP EJB
HTTP EIS
Client Web
EJB
Container
EJB
Container

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>

{
Authorization
<http-method>GET</http-method>
</web-resource-collection>
<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>

{
Authorization
<http-method>GET</http-method>
</web-resource-collection>
<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>
</user-data-constraint>
© Copyright 2000 Sun 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 Login Error

Page Form Page

1 4 5
7 9
Protected Login.jsp j_security_check Error.html
2 Resource

3
6 8

1. Request made by client

2. Is client authenticated? 6. Login succeeded, redirected to resource
3. Unauthenticated client redirected 7. Permission tested, result returned
4. Login form returned to client 8. Login failed, redirect to error page

5. Client submits login form 9. Error page returned to client

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

21
EJB Authorization

• Declarative:
– Method permissions and security roles
declared in deployment descriptor,
container performs authorization checks.
• Programmatic:
– 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. Mary's browser attempts to access the JSP component.
2. 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.
3. Mary enters her J2EE user name and password, which are passed back to the J2EE server.
4. The authentication service verifies that the user name and password exist in the default realm.
5. The Web browser is allowed to access the JSP component.
6. Mary clicks the Transfer button on the form generated by the JSP component, which calls a
JavaBeans component.
7. The JavaBeans component attempts to invoke the transfer method of the Account enterprise bean.
8. 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