Re: Instance level authorization

[Chris Ferris - Enterprise Architect - EMA]

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".