I agree with Chris Ferris 100%! This is what I have been saying in my
e-mails only Chris said it better.
The EJB 1.1 spec needs to be changed so that roles used in bean code are not
staticly defined in the DD. (Chris may want all roles to be removed, I'll be
happy if the security-role-ref ones are removed.)
-----Original Message-----
From: Chris Ferris - Enterprise Architect - EMA
To: [EMAIL PROTECTED]
Sent: 5/28/99 10:28 AM
Subject: Re: Instance level authorization
I concur with #1. I've always considered a role to be
a collection of permissions. The fact of the matter is
that roles change w/r/t the permissions they are
granted as the busines processes change (but NOT the
underlying software).
This allows much more flexibility as well as offering
much more granularity.
By requiring the specification of Role in the DTD
as well as in the EJB code, you get a proliferation of
Roles to accomodate all of the permutations and you
limit the "configurability" of the EJB by an application
assembler who may have a very different set of requirements
for allowing who to do what than is encoded in the EJB
by the Bean Provider.
I am mystified as to why the JDK1.2 security model isn't
leveraged for EJB.
Chris
Constantine Plotnikov wrote:
>
> 1) I have an impression that role is looking more like permission
rather
> then user group. And if we think about it in this way then
> isCallerRole("Account Owner") will not return true for all
> accoun owners but only for users who were granted this
> permission for bean home or bean object.
>
> 2) I would like abilility to do following in EJBContext API.
> a. to create and modify instance and home level ACL from bean code.
> b. to check specified permission for current user with respect to
these
> ACLs.
> c. to declare fixed set of permissions for current bean in DD
>
> I think that (a) somewhat solved in some EJB servers by exporting
> security API (vendors, please tell about your server).
>
> (b) and (c) are somewhat solved if we assume that isCallerRole(String)
> is
> really permission check (rather then current user group check) which
is
> calculated with respect to instance ACL by EJB server.
>
> 3) What you need is steel implementable in EJB 1.1 as a part
> of bussiness logic. I have expeirence in designing and implementing
> security in our application server (it is not yet EJB but it is on
> the way here). We were using variant like following:
>
> class TrustFundBean implements EntityBean
> {
> protected void checkRead()
> {
> try
> {
> TrustFundPermission permission =
>
> permissionHome.findByUser(ctx.getCallerPrincipal().getName(),)
> if(!permission.isGranted((TrustFund)ctx.getEJBObject(),
> TrustFundPermission.READ)
> {
> throw new SecurityException();
> }
> }
> catch(ObjectNotFound ex)
> {
> throw new SecurityException();
> }
> }
>
> private double balance( )
> {
> checkRead();
> // do work
> }
> }
>
> class TrustFundPermissionBean implements EntityBean
> {
> String user;
> int permissions;
> HashMap trustFund2permission = new HashMap();
> public TrustFundPermissionKey ejbFindByUser(String user);
> public boolean isGranted(TrustFund obj, int perm)
> }
>
> It is not optimal and is not generic enough but it can be enchanced.
>
> By subclassing or code generation cost of implementing of such check
> can be reduced. You could also consider using Aspect/J
> (http://www.parc.xerox.com/aop/aspectj) as way of conditional
> wiring such checks depending on server support for security.
>
> Constantine
>
> Richard Monson-Haefel wrote:
> >
> > 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".
>
>
========================================================================
===
> 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".
--
========================================================================
Christopher Ferris
_/_/_/_/ _/ _/ _/ _/ Enterprise Architect - EMA
_/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063
_/_/_/_/ _/ _/ _/ _/ _/ Email: [EMAIL PROTECTED]
_/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop: UBUR03-313
_/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA 01803-0903
========================================================================
========================================================================
===
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".
===========================================================================
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".
