Thanks for the reply Vlada ... I think your team should consider extending
the security-role-ref to allow for arbitrary values in the
isCallerInRole(String roleName) method. Without the ability to specify any
operationally valid role security is limited to component type and can not
be used on an instance level.
Using Mike Porter's idea for placing a role name in the instance attribute
gives you a lot of flexibility. I can do the following below:
public class Account implements EntityBean {
public double amount;
public Identity identity;
public void withdraw(double amt){
if(ctx.isCallerInRole(identity)){
...
}
else
throw new SecurityException();
}
...
}
I just completed a CORBA project where this type of authentication was
needed. We had two level of authentication functional and instance. Using
EJB's security attributes we can implicitly check for functional
authorization (can Jill do withdraws) but we need the EJBContext API to do
instance authorization (can Jill do withdraws on account 123). Obviously
this is a simple example, but most systems I work on need instance level
authorization.
I may want to group instances into roles or have a role per instance or
both. Placing the role into the persistent field allows me to do this, but
not if the roles usable from the bean are statically defined.
Would it be possible allow a derived role to be deferred to run time; not
mapped to an operational role at deployment time?
I don't want to be melodramatic, but this is really important. Mike Porter's
idea gives you the prefect excuse for not supporting instance level
authorization, but making the roles static puts the onus back on you.
Thanks,
Richard
-----Original Message-----
From: Vlada Matena
To: [EMAIL PROTECTED]
Sent: 5/26/99 11:57 AM
Subject: Re: Instance level authorization
The reason that the roles tested by the bean code using the
isCallerInRole method
must be declared in the security-role-ref element is to ensure that the
Application
Assembler and Deployer are aware of all the role names used in the code.
Otherwise,
it could be difficult to deploy the application since the deployer must
assign user groups
to the security roles, and he can do this only if he knows the set of
roles.
The isCallerInRole method allows the bean provider to parametrize the
business logic
based on the type of client. The line between what is a "security check"
versus what is
"business logic" is somewhat blurry here.
Vlada
===========================================================================
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".
