Harish Prabandham wrote:
>
> Hi,
>
> >
> > Well it seems that there is no agreed upon mechanism (lets say
> > with RMI/IIOP)
> > to propagate the client's identity (except IIOP/SSL).
> >
>
> Thats not true. There is no inter-operable way of propagating
> the client identity. But in IIOP, Service C
>> 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 hand
Hi,
>
> 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 ha
Hi,
>
> Well it seems that there is no agreed upon mechanism (lets say
> with RMI/IIOP)
> to propagate the client's identity (except IIOP/SSL).
>
Thats not true. There is no inter-operable way of propagating
the client identity. But in IIOP, Service Context fields could
be used to propagate the
Hi,
>
> How are the security credentials supposed to be passed from the
> handle to the
> EJB server in a client application like the one below:
>
> public class Foo {
> public static void main(String [] args){
> try {
>
> Handle hndl = ... // deserialize handle from a fi
Hi,
>
> Harish Prabandham wrote:
> > The security information is typically sent along with the
> > call. It is never associated with the remote object.
>
> What does "typically" mean? Are there any other possibilities (that are
> *used*)? The only option I could think of is socket connection iden
Harish Prabandham wrote:
> Hi,
>
> I do not understand the security implications of deserializing
> and serializing an java.ejb.Handle.
Well it seems that there is no agreed upon mechanism (lets say with RMI/IIOP)
to propagate the client's identity (except IIOP/SSL).
> The security information
Harish,
How are the security credentials supposed to be passed from the handle to the
EJB server in a client application like the one below:
public class Foo {
public static void main(String [] args){
try {
Handle hndl = ... // deserialize handle from a file
Hey
Lets get hardcore.
Harish Prabandham wrote:
> The security information is typically sent along with the
> call. It is never associated with the remote object.
What does "typically" mean? Are there any other possibilities (that are
*used*)? The only option I could think of is socket connecti
Hi,
I do not understand the security implications of deserializing
and serializing an java.ejb.Handle.
The security information is typically sent along with the
call. It is never associated with the remote object.
The security methods getCallerPrincipal() and isCallerInRole()
are "call" specifi
- Original Message -
From: Richard Monson-Haefel <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 02, 1999 9:19 AM
Subject: Security problem with javax.ejb.Handle
> This issue was brought up without resolution over a year ago. I had hoped that
> it would be adequate
Richard Monson-Haefel wrote:
>
> Marc San Soucie wrote:
>
> > Richard Monson-Haefel wrote:
> >
> > > Since the only method available on Handle is getEJBObject( ), its assumed
> > > that authentication is NOT used to obtain the EJBObject reference. If no
> > > authentication is used no identity is
Marc San Soucie wrote:
> Richard Monson-Haefel wrote:
>
> > This issue was brought up without resolution over a year ago. I had hoped
> > that it would be adequately addressed in EJB 1.1, but it hasn't. In fact
> > now it seems worse, because now the security flaw is mandated not implied
> > as w
Richard Monson-Haefel wrote:
> This issue was brought up without resolution over a year ago. I had hoped
> that it would be adequately addressed in EJB 1.1, but it hasn't. In fact
> now it seems worse, because now the security flaw is mandated not implied
> as was the case in EJB 1.0.
>
> Accordi
Hey
Richard Monson-Haefel wrote:
> This issue was brought up without resolution over a year ago. I had hoped that
> it would be adequately addressed in EJB 1.1, but it hasn't. In fact now it
> seems worse, because now the security flaw is mandated not implied as was the
> case in EJB 1.0.
>
> A
15 matches
Mail list logo
