I don't think I am not communicating the problem very well. I'll try again
because I believe that the problem I'm addressing is significant. If you
are new to EJB or don't understand authentication very well, than please
feel free to ignore this e-mail. If you have expertise in EJB and understand
the EJB 1.1 security architecture, I implore you to read this e-mail and
comment.
To express the problem I'll use a scenario:
BankX manages trust funds for wealthy people.
A trust fund is modeled in an entity bean, which exposes the following
remote interface:
public class TrustFund extends EJBObject{
public void deposit(double amt )
throws SecurityException , RemoteException;
public double withdraw( double amt)
throws SecurityException, RemoteException;
public double balance( )
throws SecurityException, RemoteException;
}
Fund managers manage trust funds; they make withdraws, deposits and read
balances. All fund managers (a role) are given access through the DD to
execute all the methods shown above.
There are two fund managers at BankX, Andy and Bill. There are 6 trust
funds numbered 1 - 6.
Andy is responsible for and has exclusive access to funds 1 - 3, and Bill is
responsible for and has exclusive access to funds 4 - 6. Andy can not
access funds 4 - 6 and Bill can not access funds 1 - 3.
In EJB 1.1 this granularity in authorization might be possible using both
declarative security privileges in the DD and programmatic authentication
using isCallerInRole(String roleName). Creating two new roles TrustFunds_A
and TrustFunds_B provides the programmatic authentication. Andy's
Principle is part of TrustFunds_A role and Bill is included in TrustFunds_B
role.
When a trust fund is created the role it uses is part of its persistent
state and is checked whenever a business method is invoked. Below is an
example of how this would be done in the balance( ) method in an EJB 1.1
bean.
public class TrustFundBean implements EntityBean {
public double balance;
public String trustFundGroup;
public EntityContext ctx;
private double balance( ) {
if(ctx.isCallerInRole(trustFundGroup))
// do work
else
throw new SecurityException( );
}
// more stuff follows
}
Notice that the trustFundGroup will change with each bean identity. So, for
example, trust fund #2 will have the role TrustFund_A stored in its
trustFundGroup and the trust fund #4 will have the value TrustFund_B in the
trustFundGroup field. The role being tested is dynamic; it depends on the
bean identity.
Unfortunately, In EJB 1.1 dynamic roles are not possible, so this will not
work very well. The role tested using the isCallerInRole( ) must be
statically defined in the XML DD. It could be one of several different
roles, but it can not be arbitrary. You could, for example, tell the DD
that the roles TrustFund_A and TrustFund_B may be tested while the bean is
running. Then the Application Assembler and Deployer can map these logical
roles to real roles in the operational environment.
The problem arises when I want to add a new trust fund group. Lets say two
new fund managers, Charley and Dave, are added and will share responsiblity
for all new funds (trust funds whose id is greater then 6). When a new fund
is created it will have its trustFundGroup field set to TrustFund_C.
TrustFund_C will be made an official role in the operational environment and
Charley's and Dave's principles will become members of that role.
Since the new role (TrustFund_C) is not defined in the XML DD, it can not be
used. This means that Charley and Dave will not have access to new trust
funds. To give Charley and Dave access, the bean will have to be
re-deployed with TrustFund_C added as a legitimate role in the XML DD.
On the last CORBA banking system I worked on, we had to allow the
administrator to add and remove principles to trust fund roles in real time,
and to create new trust fund roles at the administrator's discretion.
Actually the authentication was much more complex than this simple example
and the actual types of accounts were different, but the problem is still
the same.
As it stands, only roles that are statically defined in the XML DD may be
tested using the isCallerInRole(String roleName) in EJB 1.1. This is too
restrictive and will make developing EJB system with robust security a
problem. Actually, if the current design is implemented we may be forced
to use a proprietary authentication system, which will make our beans more
difficult to port.
-----Original Message-----
From: Constantine Plotnikov
To: [EMAIL PROTECTED]
Sent: 5/27/99 4:31 AM
Subject: Re: Instance level authorization
You can use getCallerIdentity() in EJB 1.0 and getCallerPrincipal() in
EJB 1.1.
and then compare principals. So your sample will look like this:
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
