Re: Security bug with application clients? (More Info)
Lachezar's second example is exactly what I tried,
and I got the same results.
I started looking at the docs related to web
clients, trying to figure out if there was something different between
web-client security and application-client security. (First, I need to
mention that I know next to nothing about web cliens or servlets.) The
Orion security primer on jollem.com seems only to set up permissions per jsp,
not actual ejb security. Is this correct, or does anybody have actual ejb
security working with web clients? (If so, is this using orion's web
server, or apache/tomcat?)
Additionally, I tried using the
RoleManager... First of all, you cannot get a role manager from a
client. It is only available inside EJBs. No problem, I
figured, I can have a "login" account, which will allow the user to connect to
an "authentication" bean to do a "RoleManager.login". Within the context
of the "authentication" bean, this seemed to work. However, on return of
the function call, the principal reverted to the "login" account. (I
suppose you could pass username & password to every method call and
"RoleManager.login" for each one... But what a hack that would be.)
Mike
- Original Message -
From:
Lachezar
Dobrev
To: Orion-Interest
Sent: Wednesday, June 13, 2001 2:31
AM
Subject: RE: Security bug with
application clients? (More Info)
Hello.
Here I want to provide more
information on the problem.
Just for
clarification.
The problem is NOT the security
itself. It works just fine.
The problem lies IMHO in caching
or something.
It is also seen only in the RMI
connection.
EXAMPLE: Consider following
situation:
We have machine OrionA and
OrionB, both running Orion.
Both have a deployed
TestEjb.
TestEjb is:
TestEjbHome
-> Home interface
TestEjbBean
-> Bean class
TestEjb
-> Remote interface.
TestEjb.doTheJob() -> returns a String containing
the
name of the machine the
bean
was executed on
(OrionA
or OrionB)
We have a standalone
client:
public class ResourceTest
{
public static
void main(String[] args){
Context CTX;
Hashtable CtxParams;
TestEjbHome TheHome;
TestEjb TheBean;
// Connect to OrionA and
execute the TestEjb bean.
CtxParams = new HashTable();
CtxParams.put (Context.INITIAL_CONTEXT_FACTORY,
"com.evermind.server.rmi.RMIInitialContextFactory");
CtxParams.put (Context.SECURITY_PRINCIPAL, "admin");
CtxParams.put (Context.SECURITY_CREDENTIALS, "123);
// Provider
is the OrionA machine
CtxParams.put (Context.PROVIDER_URL, "ormi://OrionA/TestAPP");
CTX = new InitialContext
(CtxParams);
TheHome =
PortableRemoteObject.narrow(
CTX.lookup("TestEjb"), TestEjbHome.class );
TheBean =
TheHome.create();
System.out.println( "First
execution on: " + TheBean.doTheJob() );
// Conect to OrionB and execute the TestEjb
bean.
CtxParams = new HashTable();
CtxParams.put (Context.INITIAL_CONTEXT_FACTORY,
"com.evermind.server.rmi.RMIInitialContextFactory");
CtxParams.put (Context.SECURITY_PRINCIPAL, "admin");
CtxParams.put (Context.SECURITY_CREDENTIALS, "123);
// Provider
is the OrionB machine
CtxParams.put (Context.PROVIDER_URL, "ormi://OrionB/TestAPP");
CTX = new InitialContext
(CtxParams);
TheHome =
PortableRemoteObject.narrow(
CTX.lookup("TestEjb"), TestEjbHome.class );
TheBean =
TheHome.create();
System.out.println( "Second
execution on: " + TheBean.doTheJob() );
}
}
Running the above with the
propper libraries should yeld:
First execution on:
OrionA
Second execution on:
OrionB
HOWEVER! The real sitch
returns:
First execution on:
OrionA
Second execution on:
OrionA
Another test:
Modify the code, so that the
bean returns the user name;
Modify the client, so that
it connects to one and the same provider, but with different
user_names.
Code should yeld:
First execution on:
user1
Second execution on:
user2
However it returns:
First execution on:
user1
Second execution on:
user1
In other words. Connecting once
means, that till the end you are connected to the same provider with the same
user/pass.
That's it.
Lachezar.
RE: Security bug with application clients? (More Info)
Hello.
Here I want to provide more
information on the problem.
Just for clarification.
The problem is NOT the security
itself. It works just fine.
The problem lies IMHO in caching or
something.
It is also seen only in the RMI
connection.
EXAMPLE: Consider following
situation:
We have machine OrionA and
OrionB, both running Orion.
Both have a deployed
TestEjb.
TestEjb is:
TestEjbHome ->
Home interface
TestEjbBean
-> Bean class
TestEjb ->
Remote interface.
TestEjb.doTheJob() -> returns a String containing
the
name of the machine the
bean
was executed on
(OrionA
or OrionB)
We have a standalone
client:
public class ResourceTest
{
public static void
main(String[] args){
Context CTX;
Hashtable CtxParams;
TestEjbHome TheHome;
TestEjb TheBean;
// Connect to OrionA and
execute the TestEjb bean.
CtxParams = new HashTable();
CtxParams.put (Context.INITIAL_CONTEXT_FACTORY,
"com.evermind.server.rmi.RMIInitialContextFactory");
CtxParams.put (Context.SECURITY_PRINCIPAL, "admin");
CtxParams.put (Context.SECURITY_CREDENTIALS, "123);
// Provider is
the OrionA machine CtxParams.put
(Context.PROVIDER_URL, "ormi://OrionA/TestAPP");
CTX = new InitialContext
(CtxParams);
TheHome =
PortableRemoteObject.narrow(
CTX.lookup("TestEjb"), TestEjbHome.class );
TheBean =
TheHome.create();
System.out.println( "First
execution on: " + TheBean.doTheJob() );
// Conect to OrionB and execute the TestEjb bean.
CtxParams = new HashTable();
CtxParams.put (Context.INITIAL_CONTEXT_FACTORY,
"com.evermind.server.rmi.RMIInitialContextFactory");
CtxParams.put (Context.SECURITY_PRINCIPAL, "admin");
CtxParams.put (Context.SECURITY_CREDENTIALS, "123);
// Provider is
the OrionB machine
CtxParams.put (Context.PROVIDER_URL, "ormi://OrionB/TestAPP");
CTX = new InitialContext
(CtxParams);
TheHome =
PortableRemoteObject.narrow(
CTX.lookup("TestEjb"), TestEjbHome.class );
TheBean =
TheHome.create();
System.out.println( "Second
execution on: " + TheBean.doTheJob() );
}
}
Running the above with the
propper libraries should yeld:
First execution on:
OrionA
Second execution on:
OrionB
HOWEVER! The real sitch
returns:
First execution on:
OrionA
Second execution on:
OrionA
Another test:
Modify the code, so that the
bean returns the user name;
Modify the client, so that it
connects to one and the same provider, but with different
user_names.
Code should yeld:
First execution on:
user1
Second execution on:
user2
However it returns:
First execution on:
user1
Second execution on:
user1
In other words. Connecting once
means, that till the end you are connected to the same provider with the same
user/pass.
That's it.
Lachezar.
RE: Security bug with application clients?
Please give more details. It is confusing to hear that it doesn't work when
in my case all works. I checked 3 different cases:
1) WEB authentication - OK,
2) application-clent with jndi.prop file - OK.
3) remote client with properties set via Initial Context
(+RMIInitialContextFactory instead of ClientInitialContextFact) - OK.
So what's the point?
> -Original Message-
> From: cybermaster [SMTP:[EMAIL PROTECTED]]
> Sent: &yod;&vav;&fmem; &resh;&bet;&yod;&ayin;&yod; 13 &yod;&vav;&nun;&yod; 2001 01:20
> To: Orion-Interest
> Subject: RE: Security bug with application clients?
>
> Web Application Authentication seems to work fine - a client of mine is
> using FORM based authentication for a simple app. I don't know what you
> mean
> by "dynamic" identities - we store userid info in a relational db.
>
> I have not checked the j2ee specs for required behaviour of non-Web
> application clients - what do the specs say? However, I suspect the
> problem
> may have to do with the RoleManager, which to my knowledge isn't
> configurable at this time in Orion and relies on *.xml ("non-dynamic as in
> rel. db"?) role definitions. You may want to try to use RoleManager.login
> (instead of setting the JNDI properties) on your application client - I
> have
> not tried it, so don't know wether this works. You may have noticed there
> is
> no logout method specified - I don't know how a Web Session does that
> internally (but it sure works)
>
> --peter
>
> -----Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Endres
> Sent: Tuesday, June 12, 2001 10:51 AM
> To: Orion-Interest
> Subject: Re: Security bug with application clients?
>
> > I think maybe I didn't make something clear. I am using a java
> "application" client, NOT a web client. As such, I cannot invalidate
> sessions, make posts, etc.
> >
>
> I will repeat that we have seen that Orion's InitialContext and Principal
> identity
> features do not work. They do not work in servlets, they do not work in
> client apps.
> They do not work for JMS. They do not work, Sam I am. We have given up on
> using any
> container authentication short of "guest". This is only for "dynamic"
> identities.
> It appears that static identity via the 'jndi.properties' file works ok.
>
> > Orion seems to be written primarily as a web app server, and I have seen
> very little information on using it as a direct application server (in
> Orion
> literature or in the Oracle OC4J docs.) Since very few people are using
> Orion in this way, I guess I should expect to see a few bugs here and
> there.
> (I'm guessing that this is an application-client specific issue.)
> >
>
> We use Orion with standalone Java client applications. They work fine.
> Except for authentication, which does not work.
>
>
RE: Security bug with application clients?
Web Application Authentication seems to work fine - a client of mine is
using FORM based authentication for a simple app. I don't know what you mean
by "dynamic" identities - we store userid info in a relational db.
I have not checked the j2ee specs for required behaviour of non-Web
application clients - what do the specs say? However, I suspect the problem
may have to do with the RoleManager, which to my knowledge isn't
configurable at this time in Orion and relies on *.xml ("non-dynamic as in
rel. db"?) role definitions. You may want to try to use RoleManager.login
(instead of setting the JNDI properties) on your application client - I have
not tried it, so don't know wether this works. You may have noticed there is
no logout method specified - I don't know how a Web Session does that
internally (but it sure works)
--peter
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Endres
Sent: Tuesday, June 12, 2001 10:51 AM
To: Orion-Interest
Subject: Re: Security bug with application clients?
> I think maybe I didn't make something clear. I am using a java
"application" client, NOT a web client. As such, I cannot invalidate
sessions, make posts, etc.
>
I will repeat that we have seen that Orion's InitialContext and Principal
identity
features do not work. They do not work in servlets, they do not work in
client apps.
They do not work for JMS. They do not work, Sam I am. We have given up on
using any
container authentication short of "guest". This is only for "dynamic"
identities.
It appears that static identity via the 'jndi.properties' file works ok.
> Orion seems to be written primarily as a web app server, and I have seen
very little information on using it as a direct application server (in Orion
literature or in the Oracle OC4J docs.) Since very few people are using
Orion in this way, I guess I should expect to see a few bugs here and there.
(I'm guessing that this is an application-client specific issue.)
>
We use Orion with standalone Java client applications. They work fine.
Except for authentication, which does not work.
Re: Security bug with application clients?
> I think maybe I didn't make something clear. I am using a java "application" >client, NOT a web client. As such, I cannot invalidate sessions, make posts, etc. > I will repeat that we have seen that Orion's InitialContext and Principal identity features do not work. They do not work in servlets, they do not work in client apps. They do not work for JMS. They do not work, Sam I am. We have given up on using any container authentication short of "guest". This is only for "dynamic" identities. It appears that static identity via the 'jndi.properties' file works ok. > Orion seems to be written primarily as a web app server, and I have seen very little >information on using it as a direct application server (in Orion literature or in the >Oracle OC4J docs.) Since very few people are using Orion in this way, I guess I >should expect to see a few bugs here and there. (I'm guessing that this is an >application-client specific issue.) > We use Orion with standalone Java client applications. They work fine. Except for authentication, which does not work.
Re: Security bug with application clients?
I think maybe I didn't make something clear. I am using a java "application" client, NOT a web client. As such, I cannot invalidate sessions, make posts, etc. Orion seems to be written primarily as a web app server, and I have seen very little information on using it as a direct application server (in Orion literature or in the Oracle OC4J docs.) Since very few people are using Orion in this way, I guess I should expect to see a few bugs here and there. (I'm guessing that this is an application-client specific issue.) Anyway, I could be wrong in beleiving that the problem is in stateless session beans... As Lachezar pointed out, it might be in the InitialContext. By the way, I saw this behavior in Orion 1.4.5 and in the latest release, 1.5.2. Any suggestions are appreciated, Mike - Original Message - From: Jara, Michael To: Orion-Interest Sent: Monday, June 11, 2001 7:50 PM 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
Re: Security bug with application clients?
WRONG!!!
As I see it... There is nothing in
the post, that says SESSION or HTTP or JSP or SERVLET.
I have stumbled upon this problem
many times. I've raised that question on this list many times.
However... Except for threads like
"Orion deal blah, blah" I hardly see any meaningful mail on this list. Have to
use it however.
The problem comes from other
place.
SITCH:
Step 1: Set up an InitialContext
(url, factory, principal, credentials)
Step 1.1: Do your job (create,
use, remove etc.)
< watch here >
Step 2: TRY to get another
Context with something different as parameters (let's say different user, url,
password, any of these, except for the factory).
You get an InitialContext, that
points exactly to the same target as the first one. The same target server, the
same target application, the same user, the same password. This is NOT how it
should be.
The only way to get a difefrent
context is to receive an Exception while communicating. Then you can get
different Context.
WHY???
Someone on the list proposed to use
"dedicated.connection=true" in the InitialContext hashtable parameters. Haven't
seen it to work...
Hoping, to put the guns away, and do
some job, isn't that why we are here?
Lachezar.
its
in the "clean things up" step that something went wrong.
You
need to do a session.invalidate(), and then create a new guest session with a
session.create("true"). Here is the bit in the RequestProcessor of the
BluePrint (petstore):
if (event
instanceof LogoutEvent)
{
... whatever
...
session.invalidate();
whatever
HttpSession validSession = req.getSession(true);
...whatever ...
}
This
is usually done in a servlet. I would do the same thing here. Instead of using
the client - > slsb -> whatever ... use client -> servlet -> slsb
-> whatever bean. This way, you can abstract whatever login/logout and
session control directly with the servlet, and you also abstract instancing
the slsb -> whatever bean. The servlet can also be loadbalanced (the slsb
can't be) so if you want failover capability, you get it.
regards,
the
elephantwalker
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Michael
JaraSent: Monday, June 11, 2001 6:51 PMTo:
Orion-InterestSubject: 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
RE: Security bug with application clients?
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
RE: Security bug with application clients?
its in
the "clean things up" step that something went wrong.
You
need to do a session.invalidate(), and then create a new guest session with a
session.create("true"). Here is the bit in the RequestProcessor of the
BluePrint (petstore):
if (event
instanceof LogoutEvent)
{
... whatever
...
session.invalidate();
whatever
HttpSession validSession = req.getSession(true);
...whatever ...
}
This
is usually done in a servlet. I would do the same thing here. Instead of using
the client - > slsb -> whatever ... use client -> servlet -> slsb
-> whatever bean. This way, you can abstract whatever login/logout and
session control directly with the servlet, and you also abstract instancing the
slsb -> whatever bean. The servlet can also be loadbalanced (the slsb can't
be) so if you want failover capability, you get it.
regards,
the
elephantwalker
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Michael
JaraSent: Monday, June 11, 2001 6:51 PMTo:
Orion-InterestSubject: 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
