>I don't think it is a good idea to prevent client from obtaining a >reference. With that model a client either has access to everything or >nothing. In many situations a client with his security role is allowed to >call some method on a object, whereas not the others. A simple security >model may allow the role to call all get methods and forbid any set methods. >So IMHO the handle should play the same role as IOR in CORBA, which contains >the information about how to locate the object. SO you can save the handle >or mail the handle to any other people, which doesn't mean that the other >people are automatically allowed to access everything with this handle. >As Harish said, the security context information should be delivered in the >runtime and not saved in the handle. In the case of the Handle, it may not be practical or desirable to control access to it because it's no good to carry security info around with the handle. But for server-side object references in general, whether they can be obtained openly to the world is application specific. I am sure that most of the object references out there in naming services such as JNDI are not publicly accessible by everyone. But then, there are certainly applications that need to have their object references open to the world. The point is that access control should be enforced as early and practically as possible. -JL > -----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 >
