Don't jump into the conclusions. To my limited experience the Orion's
authentication is very intelligent and tolerant to the user mistakes. For
reference you may use OCJ4 manual (Oracle app server, see mail list ). I
recommend reading it carefully. 

> -----Original Message-----
> From: Michael Jara [SMTP:[EMAIL PROTECTED]]
> Sent: &yod;&vav;&fmem; &shin;&lamed;&yod;&shin;&yod; 12 &yod;&vav;&nun;&yod; 2001 03:51
> To:   Orion-Interest
> Subject:      Security bug with application clients?
> 
> Hi,
>  
> I'm trying to get the security portion of a project working, in which a
> java client connects to a stateless session bean after login.  As far as I
> can tell, Orion doesn't seem to properly pass around principal objects in
> stateless session beans.
>  
> This is the sequence that my test client runs:
>  
> 1. Prompt user for user ID & password
> 2. Create an InitialContext containing the user ID and password (as
> "java.naming.security.principal" and "java.naming.security.credentials",
> respectively.)
> 3. Look up the stateless session bean's home
> 4. home.create() the stateless session bean
>  
> So far, so good.  The stateless session bean correctly identifies the user
> ID within its session context's principal.  Now I clean things up and
> repeat the process:
>  
> 5. remove() the stateless session bean
> 6. close() the InitialContext (just in case... I even went so far as to
> remove all of its environment properties.)
> 7. Log on again: prompt for a different user ID & password
> 8. Create a new initial context as in step 2.
> 9. Look up the stateless session bean's home
> 10. home.create() the stateless session bean
>  
> This is where things go wrong.  I get the principal out of the stateless
> session bean's session context, which indicates that I'm logged in as the
> first user!  The problem is that the bean is never calling
> "setSessionContext" on the second creation.  If I re-start the client
> however, it works correctly.
>  
> The only way I can think of to get around this is to use a stateful
> session bean instead...  I don't like that, because I don't need to
> maintain state!  Has anyone else encountered this problem?  Found a
> solution?
>  
> Thanks,
> Mike

Reply via email to