You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Martin Vysny <mv...@whitestein.com> on 2008/06/17 09:37:02 UTC
OpenEJB local interfaces JNDI security
Hi guys,
another issue ;) I tried to use JNDI security with OpenEJB - that is,
constructing InitialContext with properties Context.SECURITY_PRINCIPAL
and Context.SECURITY_CREDENTIALS set. It works beautifully, however when
another InitialContext is constructed (first one is closed using
Context.close()) the following exception occurs:
Caused by: javax.naming.NamingException: Cannot instantiate an IntraVM
InitialContext. Exception: javax.naming.AuthenticationException User
could not be authenticated: karolko [Root exception is
javax.naming.AuthenticationException: User could not be authenticated:
karolko [Root exception is javax.security.auth.login.LoginException:
Thread already associated with a client identity. Refusing to
overwrite.]]
at
org.apache.openejb.client.LocalInitialContextFactory.getIntraVmContext(LocalInitialContextFactory.java:116)
at
org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:41)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.<init>(InitialContext.java:197)
at
com.whitestein.fe.client.ejb.ClientCommunicationImpl.newClient(ClientCommunicationImpl.java:109)
... 16 more
Caused by: javax.naming.AuthenticationException: User could not be
authenticated: karolko [Root exception is
javax.security.auth.login.LoginException: Thread already associated with
a client identity. Refusing to overwrite.]
at
org.apache.openejb.core.ivm.naming.InitContextFactory.getInitialContext(InitContextFactory.java:53)
at
org.apache.openejb.client.LocalInitialContextFactory.getIntraVmContext(LocalInitialContextFactory.java:114)
... 22 more
Caused by: javax.security.auth.login.LoginException: Thread already
associated with a client identity. Refusing to overwrite.
at
org.apache.openejb.core.security.AbstractSecurityService.associate(AbstractSecurityService.java:174)
at
org.apache.openejb.core.security.AbstractSecurityService.associate(AbstractSecurityService.java:60)
at
org.apache.openejb.core.ivm.naming.InitContextFactory.getInitialContext(InitContextFactory.java:51)
... 23 more
Probably the client identity should be removed from ThreadLocal on
Context.close(), or J2SE security (doPrivileged) could be used to hold
the principal. Should I open a bug?
Thanks,
Martin
Re: OpenEJB local interfaces JNDI security
Posted by Martin Vysny <mv...@whitestein.com>.
On Tue, 2008-06-17 at 14:03 -0700, David Blevins wrote:
> On Jun 17, 2008, at 12:37 AM, Martin Vysny wrote:
>
> > Probably the client identity should be removed from ThreadLocal on
> > Context.close(), or J2SE security (doPrivileged) could be used to hold
> > the principal. Should I open a bug?
>
> Maybe not a bug, but definitely file a JIRA and mark it as
> "Improvement". A way to logout would be a good feature.
>
> Context.close() is one option I hadn't thought of before. Could
> work. It sort of gives the impression that the security data is
> scoped at the Context, which wouldn't be a bad feature either.
> Anyway, we can definitely get something going here.
>
> -David
>
Looks good, thanks! I opened an improvement request:
https://issues.apache.org/jira/browse/OPENEJB-822
>
--
Mgr. Martin Vysny | mvy@whitestein.com
Software Engineer
Whitestein Technologies s.r.o | www.whitestein.com
Panenska 28 | 811 03 Bratislava | Slovak Republic
Main +421 2 5443-5502 | Direct +421 2 5930-0717
Re: OpenEJB local interfaces JNDI security
Posted by David Blevins <da...@visi.com>.
On Jun 17, 2008, at 12:37 AM, Martin Vysny wrote:
> Probably the client identity should be removed from ThreadLocal on
> Context.close(), or J2SE security (doPrivileged) could be used to hold
> the principal. Should I open a bug?
Maybe not a bug, but definitely file a JIRA and mark it as
"Improvement". A way to logout would be a good feature.
Context.close() is one option I hadn't thought of before. Could
work. It sort of gives the impression that the security data is
scoped at the Context, which wouldn't be a bad feature either.
Anyway, we can definitely get something going here.
-David