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:
> public class Account implements EntityBean {
> public double amount;
> public Principal principal;
>
> public void withdraw(double amt){
> if(ctx.getCallerPrincipal().equals(principal)){
> ...
> }
> else
> throw new SecurityException();
> }
> ...
> }
I do not know where EJB servers will store Principal fileds in CMP
(I think they should, but vendors may think otherwise), but you could
store name
instead.
> public class Account implements EntityBean {
> public double amount;
> public String userName;
>
> public void withdraw(double amt){
> if(ctx.getCallerPrincipal().getName().equals(userName)){
> ...
> }
> else
> throw new SecurityException();
> }
> ...
> }
Constantine
Richard Monson-Haefel wrote:
>
> 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".
===========================================================================
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".
