Hi,
I don't think it is a good idea to prevent client from obtaining the
reference. In this way you are making an all or nothing differentiation. In
many situations the security model is very flexible, which allows the same
client to call some method, while not others. A simple security model may
allow a role to call all getter methods and forbid all setter methods. If
the client who has this role is not even allowed to obtain the reference,
how can he get the getter method called. So the access control should occur
at the runtime, where the security information must be delivered from the
runtime context and not from the handle.
IMHO a handle is something like IRO in CORBA which contains information
about how to locate the remote object and nothing about the context
information. Imagine you want to mail the handle to somebody else, so that
he can call the remote object too. If the security information were saved in
the handle, then the other person would automatically get the full access as
you.
So I agree with Harish, that the handle should not contain any security
information, ehich must be delivered in another way at runtime.
Dapeng Wang
> -----Urspr�ngliche Nachricht-----
> Von: Jian Lin [SMTP:[EMAIL PROTECTED]]
> Gesendet am: Donnerstag, 9. September 1999 15:19
> An: [EMAIL PROTECTED]
> Betreff: Re: Security problem with javax.ejb.Handle
>
> >> This also implies that the JAAS must be used -- or some similar
> container
> >> specific mechanism -- OR that the EJB object has been deployed to
> accept
> >> anonymous clients. If none of this is true, executing methods on
> >> the EJBObject
> >> or even obtaining the EJB object reference from the handle should fail.
> >>
>
> > It does not matter whether the failure occurrs while getting the object
> > reference from the handle or when the client makes a method call. Does
> it?
>
>
> It would be desirable to prevent the client from obtaining the reference
> in the
> first place if it is not authorized to invoke any of the methods from a
> resource
> consumption point of view. To go even further, a client could be denied
> access
> to a handle if it's not authorized to. But that requires an entire
> different
> layer of access control implementation. In the case of EJBs, for instance,
> the
> beans have their access control. But access to EJBHome object lookup is
> controlled separately by JNDI.
>
> -Jian
>
> ==========================================================================
> =
> 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".
