07/16/2003

EJB-tier
Security

This session is EJB-tier security. This session should be viewed

along with Web application security presentation since J2EE security
covers both Web-tier and EJB-tiers.
07/16/2003

Sang Shin
sang.shin@sun.com
www.javapassion.com/j2ee

Technology Evangelist
Sun Microsystems, Inc.
07/16/2003

Disclaimer & Acknowledgments

? Even though Sang Shin is a full-time employee of Sun
Microsystems, the contents here are created as his own
personal endeavor and thus do not reflect any official
stance of Sun Microsystems.
? Sun Microsystems is not responsible for any contents in
this presentation.
? Acknowledgments
– Large number of slides are made from the contents of the book
"Applied Enterprise JavaBeans" Technology written by Kevin Boone (Sun
Microsystems), published by Prentice Hall [1]
07/16/2003

Revision History & Things to Do

?
04/14/2003: version 1, created (Sang)
?
06/25/2003: version 2, speaker notes are added (Sang)
?
Things to do
? Some duplicate information need to be cleaned up
07/16/2003

Agenda
? Security issues (review)
? J2EE security architecture & concepts
? Authorization (at EJB-tier)
? Authentication (at EJB-tier)
? Confidentiality and integrity (at EJB-tier)
? Security context propagation (at EJB-tier)
? Issues to be discussed in “J2EE security
best practices” (advanced J2EE
programming course)
5

This is the agenda of this presentation. First we will go over

general security issues. This is a review of what we already talked
about during Web application security.

Then we will talk a little bit on J2EE security architecture and

concepts. Then we will talk about three key security issues at EJB-
tier: authentication, authorization, and confidentiality. There are
the issues we dealt with in Web-tier as well.

We will then talk a bit on security context propagation. Then we

will have a slide that lists the advanced security issue, which we
will deal with during advanced J2EE class.
07/16/2003

General Security
Issues (Review)

Now let's quickly go over general security issues. This is what

we already talked about during Web application security session.
07/16/2003

General Security Issues

? Authentication for identity verification
– Making sure a user is who he claims he is
? Authorization (Access control)
– Making sure a resource gets access only by user who
as access privilege
– The user has to be authenticated first
? Confidentiality (Privacy)
– Protecting the sensitive data from prying eyes while
it is on the wire

These are general security issues which we talked about during the security
basics session. So let's just quickly review them here again.

First, in a networking environment, a user (or program entity) has to prove

his/her (its) identity. And we call it authentication. So by using appropriate
authentication scheme, we can be assured that a user (or program entity) is
in fact who he/she (it) claims he/she (it) is.

Next, authorization. Authorization is the same thing as access control.

Authorization is a process of making sure a resource gets accessed only by a
user who has access privilege. And of course, it is assumed that the user has
been authenticated already.

Confidentiality is sometimes called privacy and it means that the data should
be accessible only to the party the data is intended. It means nobody can
07/16/2003

General Security Issues

? Data integrity
– Making sure data does not get tampered with while it is
being transported on the wire
? Non-repudiation
– Proving to a 3rd-party that your communicating partner
performed a particular transaction
? Auditing
– Recording transactions
? Firewall
– How to protect enterprise's internal resources from the
internet
8

Data integrity is making sure data does not get tampered with while it is on
the wire.

Non-repudiation means being able to prove to a 3rd-party that your

communicating partner has performed a particular transaction.

Auditing is recording transactions. Also firewall protects enterprise's

internal resources from the outsiders.

The security issues on this slide are not standardized yet by J2EE specification
but most of the commercial vendors support these security features as value-
added features.
07/16/2003

J2EE Security
Architecture

Now let's quickly go over J2EE security architecture.

07/16/2003

J2EE Security Architecture

EJB Security model Web-tier Security model
(method permissions) (URL permissions)

Roles

Container security services

Principals

Transport level security (SSL, TLS)

Network infrastructure

source: Applied Enterprise JavaBeans[1]

This picture shows rather simplified J2EE security architecture. As was

mentioned in previous slide, J2EE security covers both web-tier and EJB-tiers.
At Web-tier, the access control is performed against each web resource which is
represented in the form of an URL while at EJB-tier, the access control can be
applied against each business method of a bean.

At both web-tier and EJb-tier, the concept of abstract role is important. The
container can enforce access control based on roles defined in the web-tier and
EJB-tier. Under J2EE, user credentials are represented in the form of Principal
objects. The Principal objects are created from the actual user identity
information that was entered by user.

Also under J2EE arcitecture, the transport level security such as SSL can be
leveraged for confidentiality.
07/16/2003

Container Security Services

? Container enforces security policy specified in
the deployment descriptor
– Web container for Web-tier security policy
– EJB container for EJB-tier security policy
? Container must protect JVM and host
machine from unauthorized access by other
applications
– Vendor specific solutions

11

Now let's talk a bit on security services that J2EE containers provide. One of
the system services that container provides is enforcing security policy that is
specified in the deployment descriptor. The security policy can be specified
by bean developer and deployer of the application. Obviously Web-tier
container enforces security policy specified in web.xml deployment descriptor
and EJB container will enforce security policy specified in ejb-jar.xml
deployment descriptor.

Other security service that J2EE container has to provide implicitly is to

protect JVM and host machine from unauthorized access by other
applications.
07/16/2003

Transport-layer Security
? Provides encryption over TCP/IP
connection
? SSL & TLS
? Supports encryption
? Between Web browser and Web-tier
components
? Between EJB container to EJB container (from
EJB 2.0)
? Between CORBA client and EJB container (from
EJB 2.0)

Now let's talk about transport layer security that is being

leveraged under J2EE architecture. By transport layer security,
we are basically talking about SSL (or TLS). And as we talked
about in detail in Web application security session, SSL supports
confidentiality of data such as credit card information or user's
password between a browser and Web container.

SSL secures communication between EJB container and

container. (EJB 2.0 spec mandates the SSL support between
containers.) Same can be said between CORBA client and EJB
container.
07/16/2003

J2EE Security is an Abstraction

? Differences exist among operating environments
– User credentials are represented in different ways
? username/password, certificate, kerberos
? groups are constructed in different ways

– User credentials and access rights are maintained

using different schemes
? LDAP server, Database, Flatfile
? OS specific ways
? J2EE security scheme must accommodate these
differences, consequently should be represented
in abstract fashion 13

Now we talked about this during Web application security session. But I
would like to talk about this one more time because it is important for you to
understand this.

J2EE security is an abstraction. What this means is that when you are writing
your J2EE application, basically you have to deal with the user identity as an
abstraction. This is because when you are writing your J2EE application, you
don't know over which operating system or App server or realms your
applications will run. That is, different deployment environment have
different ways of maintaining their user identity information. Some
environment use username/password while others might use certificates or
kerberos. Some environments might use combination of theses. Also the
user identity information can be maintained using different schemes, for
example, LDAP server, or database or file system. In some cases, they are
tied up with operating system specific ways.
07/16/2003

J2EE Security is an Abstraction

? J2EE security scheme cannot be expressed in
terms operating environment specific
username/password, groups, access control
? J2EE security is represented in terms of
– Principals
– Roles
– Role mappings
? Mapping operating environment specific user
credentials to J2EE principals, roles are done
in product specific ways
14

This is continuation of the previous slide. So J2EE security scheme cannot be

expressed in terms of operating environment specific ways.

Now under this abstract J2EE security scheme, there are notions of Principals,
Roles, and Role mappings. By “Role”, we mean abstract “Roles”, which in
turn need to be mapped into concrete roles during deployment time.
07/16/2003

J2EE Access control is expressed

in terms of Roles
? Each role is associated with a particular set of
permissions (policy)
– “ employee” role can view only his/her salary info
– “ HR admin” role can view everyone's salary info
? Abstract Security role
– Bean developers should be able to define the access
control with no dependence on security schemes of
a particular operating environment
– Mapping between abstract security roles and
operating environment specific usernames and
groups have to be done at the time of deployment
15

So J2EE access control is expressed in terms of roles. Each role is associated

with a particular set of permissions. And we will call this “policy” or
“security policy”. For example, an “employ” role can view only his or her
salary and while “HR admin” role can view everyone's salary information.

Now just to repeat the concept of abstract security role we talked about in
the previous slides, bean developers should be able to define the access
control with no dependence on security schemes of a particular operating
environment, that is, no dependence on the security schemes of operating
systems, app server products, or even operating environments. What this
means is that there has to be a mapping between abstract security roles and
operating environment environment specific user names and groups at the
time of deployment.

Now let's talk about an example scenario in the following slide.

07/16/2003

Role Mapping
Group 1
User1 User2 User3
Vendor-
specific
Principal1 Principal2 Principal3

Role1 Role2

J2EE
Role Role
reference1 reference2

16
source: Applied Enterprise JavaBeans[1]

This picture shows an example scenario where vendor or

operational envioronment specific user names, and groups are
mapped into abstract roles.

Let's say, a particular operational environment (maybe using OS

specific or App server specific) has user1 and user2, who belong
to group1. And there is another user, user3. These could be OS
specific usernames and groups. Now when these users are
authenticated against J2EE compliant app server, they are
represented in the form of Principals. The actual contents of
Principals are vendor-specific. These Principals are then mapped
into concrete roles, like Role1 and Role2, which are then mapped
into Abstract roles called Role references.
07/16/2003

J2EE Security Enforcement is done

by Containers not by Components
? Authentication is performed by Container
– For a user using a browser, login-page gets displayed
by Web-tier
– For standalone EJB client talking to EJB tier, Client
container is used
? Client container is wrapper of EJB client code

? Client container authenticates a user first before

it passes control to the client code

? Role-based authorization (access control) is
mostly done by Container
17

Now under J2EE architecture, the security enforcement is done by containers

not by components. For example, at web-tier, when a user tries to access a
protected web resource for the first time, the web container will authenticate
the user first then enforce access control. At EJB-tier, if a standalone EJB
client application tries to perform a method of an EJB bean, the client
container will perform the authentication first. (Please note that this client
container is vendor specific, that is, J2EE specification does not address how
EJb client container is to be built.) As for the role-based access control,
container again enforces the access control even though fine-grained access
control can be also performed at the programmatic level.
07/16/2003

Declarative & Programmatic

? Declarative
– Deployment descriptor specifies who can access
what EJB and what methods
? Programmatic
– Program can query identity of the user to make
decisions based on user identity or business logic
? Declarative and Programmatic are typically
used together

18

Now let's talk a little bit of declarative versus programmatic access control.
The declarative access control means the access control policy is specified
inside the deployment descriptor. For example, at EJB tier, a bean developer
or deployer can specify which role can access what methods. The
programmatic access control means you as a bean developer can enforce
access control based on programming logic. For example, you can enforce
access control in such a way that only people who belong to a particular role
can invoke a certain set of methods of a bean. In general, both declarative
and programmatic access controls are used together.
07/16/2003

Propagated & Delegated

? Protection Domain across JVMs
? CSIv2 (from CORBA) to support Identity
Assertion
? The identity doesn’t have to be the
same as JAAS user identity

(read the slide)

07/16/2003

Authorization
(Access Control)
07/16/2003

4 Types of Authorization
(Access Control) over J2EE
• Web-tier vs. EJB-tier
– Can be used together
• Declarative vs. Programmatic
– Can be used together
• 4 possible combination
– Declarative access control at Web-tier
– Programmatic access control at Web-tier
– Declarative access control at EJB-tier
– Programmatic access control at EJB-tier
21
07/16/2003

Web-tier vs. EJB-tier

Web-tier EJB-tier
• (D) Access control to • (D) Access control to
Web resources bean methods
• (D) Declared in • (D) Declared in EJB
web.xml deployment descriptor
• (D) Enforced by web • (D) Enforced by EJB
container container
• (P) Coded in servlet • (P) Coded in EJB bean
or JSP

(D): Declarative (P): Programmatic access control

First let's compare web-tier access control versus ejb-tier access control.
At both tiers, there could be both declarative and programmatic access
control.

For example, at web-tier, access control is applied to web resources such

as servlet or JSP pages while at EJB tier, the access control is applied to
the bean methods.

At web tier, the declarative access control is specified within web.xml

deployment descriptor while at EJB tier, it is specified at EJB deployment
descriptor. And at web tier, the access control is enforced by web
container while at EJB tier it is enforced by EJB container.

In terms of programmatic access control, at web-tier, the programmatic

07/16/2003

Declarative vs. Programmatic

Declarative Programmatic
• Access control is • Access control is coded
declared in in your program
deployment • Your code handles
descriptor access control
• Container handles • Can handle fine-
access control grained access control,
• Does not handle i.e. instance-based or
fine-grained access business logic based
control, it is all or access control
nothing deal (class-
based)

Now let's compare declarative access control against

programmatic access control.

In declarative access control, the access control logic is

declaratively specified in deployment descriptor and then it is the
container that handles the access control. In programmatic
access control, on the other hand, the access control logic is
coded in your program.

By the way, declarative access control can be used together with

programmatic access control.

Now the reason you might want to implement programmatic

access control is the declarative access control scheme does not
07/16/2003

Declarative
Authorization
at EJB-tier

Ok. let's talk about declarative access control at EJB-tier first.

07/16/2003

Steps for Declarative

Authorization at EJB-tier
1. Deployer maps actual user identities to
security roles using vendor specific tools
2. Deployer declares security roles in the
deployment descriptor
3. Deployer declares method permissions in the
deployment descriptor for each security role

25

Now how do you implement declarative access control at EJB-tier?

One of the nice thing about using declarative access control is
that the bean developer does not really have todo any work. In
other words, in declarative access control scheme, it is the
deployer who specifies security requirement in the deployment
descriptor and it is the responsibility for the container to enforce
the access control.

So in declarative access control, the deployer declares security

roles first. Then he declares method permissions for each security
role.

It is assumed that the deployer or system administrator have

mapped user identities to security roles.
07/16/2003

Step 1: Deployer maps actual user

identities to actual roles
• Different operational environments
maintains different set of user identities
(principals) using different schemes
– Userid/password file, LDAP, Kerberos
• Different containers provide different
schemes/tools for mapping user identities
to actual roles

26

Now we also assume deployer or administrator has mapped actual

user identities to actual roles.
07/16/2003

Step 2: Deployer declares Security

Roles
<enterprise-beans>

<assembly-descriptor>
<security-role>
<description>People manages other people</description>
<role-name>manager</role-name>
</security-role>
<security-role>
<description>People who are employeed</description>
<role-name>employee</role-name>
</security-role>
</assembly-descriptor>
...

27

So here the deployer declares two security roles, manager and

employee roles.
07/16/2003

Step 3: Deployer declares Method

Permissions
<enterprise-beans>

<assembly-descriptor>
<method-permission>
<role-name>manager</role-name>
<method>
<ejb-name>EmploySalary</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
<method-permission>
<role-name>employee</role-name>
<method>
<ejb-name>EmploySalary</ejb-name>
<method-name>doNothingMuch</method-name>
</method>
</method-permission>
</assembly-descriptor>
...
28

In step 3, the deployer declares method permissions for each

security role. So in this example, manager role can call any
method of the bean called EmployeeSalary while employee role
can call only doNothingMuch method.
07/16/2003

Programmatic
Authorization
at EJB-tier

Now let's talk about programmatic authorization at ejb-tier.

07/16/2003

Steps for Programmatic

Authorization at EJB-tier
1. Deployer maps actual user identities to
actual roles using vendor specific tools
2. Bean provider writes programmatic
authorization logic inside the bean code
3. Bean provider declares abstract security roles
in the bean's deployment descriptor
4. Deployer maps abstract security roles to
actual roles (for a particular operational
environment) in deployment descriptor
30

This is the list of steps for performing programmatic authorization

at ejb-tier.

First, bean provider write programmatic authorization logic inside

the bean code. Next, the bean provider declares abstract security
roles in the bean deployment descriptor.

Now when this bean gets deployed in a particular operational

environment, deployer then maps these abstract security roles to
actual roles in that particular operational environment. I will
explain the difference between abstract role and actual role later
on in a bit more detail.

Then deployer maps actual user identifies to actual roles using

07/16/2003

Step 2: Access control methods

Bean developer can use
public interface javax.ejb.EJBContext{
...
// Find out who is calling your bean method
public java.security.Principal getCallerPrincipal();

// Is the caller in a particular role?

public boolean isCallerInRole(String role);
...
}
31

So in step 2, bean provider write programatic authorization logic.

In EJB, EJB Context interface provides two methods for this

purpose, one is called getCallerPrincipal() method and the other
is isCallerinRole(). The getCallerPrincipal() method is used to get
caller's Principal object from which login name can be extracted.
And the isCallerinRole() method is used to find out if a caller is in
a particular role or not.
07/16/2003

Example: “Employees” can only

access their own Salary Information
public double getSalary(String employeeId) {
java.security.Principal callerPrincipal =
ctx.getCallerPrincipal();
String callerId = callerPrincipal.getName();

// “manager” role can read employee salary information

// employee can read only his/her own salary information
if ( (ctx.isCallerInRole(“manager”)) ||
((ctx.isCallerInRole(“employee”)) &&
(callerId == employeeId)) ) {
// return Salary information for the employee
getSalaryInformationSomehow(employId);
} else {
throw new SecurityException(“access denied”);
}
}
32

So in this example, the access control logic says that manager

role can read salary information of everyone while employee
rolecan read only his or her salary information. So here you get
the caller's principal object and get the caller id string from it
and check if that matches the employee id that is passed as a
parameter.
07/16/2003

Step 3: Bean provider declares

abstract security roles
<enterprise-beans>
<session>
<ejb-name>EmploySalary</ejb-name>
<home>acme.EmploySalaryHome</home>
...
<!-- Bean provider declared abstract security roles -->
<security-role-ref>
<description> abstract “manager” role </description>
<role-name>manager</role-name>
<security-role-ref>
...
<session>
...
</enterprise-beans> 33

Now in step 3, bean provider declares abstract security roles in

the bean's deployment descriptor.

Now these roles are called abstract roles because they are not
really actual roles defined in the actual operational environments.
In other words, as a bean developer, you don't know how each
operational environment define their users and the roles they
play. So in the bean you use the abstract roles.

And these abstract roles need to be mapped to actual roles for a

particular operational environment at the deployment time. And
that is the next step.
07/16/2003

Step 4: Deployer maps abstract

security roles to actual roles
<enterprise-beans>
<session>
...
<!-- Bean provider declared abstract security roles -->
<security-role-ref>
<description> abstract “manager” role </description>
<role-name>manager</role-name>
<role-link>managerOfAcme</role-link>
<security-role-ref>
<session>
<assembly-descriptor>
<!-- Deployer declared real security roles -->
<security-role>
<description> real “manager” role in Acme corporation </description>
<role-name>managerOfAcme</role-name>
<security-role>
</assembly-descriptor>
...
</enterprise-beans> 34

So here in this example, abstract role called manager is mapped

to actual role called managerofAcme.
07/16/2003

“ EJB Role Mapping”

Code and Deployment Descriptor

$ $ EJB-1 “payroll” EJB-2 “payroll-dept”

Provider

Assembly Descriptor
Method level
“ payroll-dept” permissions
Assembler

Container Specific
“ payroll-group” (Operational User)
Deployer

Bean provider may and will probably not use role-names that are compatible with
your application
The assembler maps the bean provider’s role-names with links to role-names
used by the application
The <role-link> tag in the EJB container does not have the same use as in
the Web container, where <role-link> is a direct link to the operational
role
The container provides deployment tools to map the assembler’s logical roles to
the containers operational roles.
This is container specific
07/16/2003

Authentication

O
07/16/2003

J2EE Authentication
? J2EE security is an abstraction of real security
infrastructure
? Authentication does not resolve into actual
(operating environment specific) userid but
resolves into a “Principal”
? Principal is an abstract user identity
– A user might have multiple Principals depending on
authentication schemes (username/password,
certificate-based, eyescan, etc..)

37

T
07/16/2003

Authentication at EJB-Tier
? Authentication is the job of the container
not the EJB developer
? Authentication schemes are container
specific
– Recommended, but not required:
• Username/password
• X.509
• Kerberos
? Programmatic authentication is not
supported
07/16/2003

Two Possible Authentication

Schemes in J2EE
? Option 1
– Web-tier collects information about a user
(userid/password, certificate, etc.) and forwards
them for authentication at EJB-tier
? Option 2
– Web-tier collects information about a user
(userid/password, certificate, etc.) and
authenticates the user at Web-tier
– Web-tier then forwards the identity of a user (in the
form of Principal) to the EJB-tier
39

T
07/16/2003

In Practice, Option 2 is used

? Same role-base security can be used at both
Web-tier and EJB-tier
– Roles can be shared
? Transfer of Principal information between
Web-tier and EJB-tier is done via RMI over
IIOP
– It can be SSL protected (from EJB 2.0)

40

T
07/16/2003

Authentication Framework of J2EE

Authentication Trust Credential Mapping

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

Initiator Intermediate

41
07/16/2003

Protection Domains
for the J2EE Platform

N
07/16/2003

How does a Standalone EJB Client gets

authenticated against EJB-Container?
? Issue
– There is no standard way for EJB client to collect user
credentials (unlike Browser client)
? Solution
– Usage of Client container

43

T
07/16/2003

Client Container
? Client container is wrapper of EJB client
application
? Client container collects user credentials and
authenticate the user against the EJB server
before it passes control to the client program
– User credential could be
? username/password pair, certificate
– Client container implementation varies in their
sophistication
? graphical display or text display or part of library
44

T
07/16/2003

Client Container for J2EE RI

? Client container is created during
deployment time
? Example:
– runclient -client RosterApp.ear -name RosterClient
-textauth

45

T
07/16/2003

EJB-tier Confidentiality
& Integrity

O
07/16/2003

Confidentiality for
EJB Components
? J2EE 1.3 Containers must support SSL
3.0 and TLS 1.0
? Configuration is container-specific
? Not declared in deployment descriptor
07/16/2003

Integrity
? Ensures that a message has not
been modified
? Java technology provides programmatic
support for message digests
– java.security.*
– Java Cryptography Extension (JCE)

48

U
07/16/2003

Possible Combinations
EJB-tier Security

O
07/16/2003

Possibilities of EJB-tier Security

1.No authentication, no authorization, no
encryption (default)
2.Authentication by password, authorization,
but no encryption
3.Authentication by password, with
encryption
4.Authentication by certificate and
encryption

50

U
07/16/2003

Security Context
Propagation at EJB-tier

OK. Let's talk a little bit on security context propagation at EJB-tier.

07/16/2003

Security Context Propagation

? Which security context (Principal)
does P2 carry?

EJB1 EJB2

Client P1 P2
method1() method2()

source: Applied Enterprise JavaBeans[1] 52

I
07/16/2003

“ EJB Identity” at P2
? Delegated
<security-identity>
<run-as>
<role-name>
RoleNameTobePropagated
</role-name>
</run-as>
</security-identity>

? Propagated
<security-identity>
<use-caller-identity/>
</security-identity>

53

G
07/16/2003

Example: Propagated
• Propagate client's identity to other
beans it calls
<enterprise-beans>
...
<session>
<ejb-name>EmployeeManagement</ejb-name>
<home>examples.EmployeeManagementHome</home>
...
<security-identity
<use-caller-identity/>
</security-identity>
</session>
...

54

S
07/16/2003

Example: Delegated using “run-as”

• Delegate the identity of the role admins to
all other beans it calls
<enterprise-beans>
...
<session>
<ejb-name>EmployeeManagement</ejb-name>
<home>examples.EmployeeManagementHome</home>
...
<security-identity>
<run-as>
<role-name>admins</role-name>
</run-as>
</security-identity>
</session>
...
55

I
07/16/2003

Issues to be talked
about in “J2EE Security Best
Practices” session in
Advanced J2EE Programming

S
07/16/2003

J2EE Security Best Practices

• Instance-based authorization (as opposed
to class-based authorization)
• A manager can access salary information of
only the people he manages
• How to add a user to a role in a vendor-
independent way
• How to use programmatic access control
• Administration
• Firewall
57

I
07/16/2003

Resources
07/16/2003

Resources Used
? Applied Enterprise JavaBeans Technology written by
Kevin Boone (Sun Microsystems, Inc.), published by
Prentice Hall, 2003 [1]
? J2EE Tutorial in java.sun.com, 2002 [2]
? Mastering Enterprise JavaBeans, 2 nd edition written by
Ed Roman, published by Wiley, 2002 [3]
07/16/2003

Live your life

with Passion!