authorization check failed (...) while invoking method rebind_java_object

[Ben_]

Hello,

Platform: WAS-ND v5.1.1.5

The following is seen in the logs and prevents the application from running.

It seems Hibernate is not authorized to bind its Session object into the
Namespace.

Admin credentials are coded in <WebSphere>/AppServer/properties
soap.client.properties.

It seems that restarting something helped somehow (we did so much that I
can't tell if it was restarting the Application, Node Agent or DM or all
that did it), but error comes back again.

Help appreciated, thx.

[10/28/05 15:22:02:343 CEST] 2bd195a2 RoleBasedAuth A SECJ0305I: Role based
authorization check failed for security name <null>, accessId
unauthenticated while invoking method rebind_java_object on resource
NameServer and module /com/ibm/ws/naming/bootstrap/xml/NameServer.xml.
[10/28/05 15:22:03:890 CEST] 2bd195a2 Helpers W NMSV0610I: A
NamingException is being thrown from a javax.naming.Context implementation.
Details follow:
Context implementation: com.ibm.ws.naming.jndicos.CNContextImpl
Context method: rebind
Context name: MyCell/nodes/Node01/servers/ACME_Server
Target name: services/hibernateSF
Other data: Object to bind: org.hibernate.impl.SessionFactoryImpl@1aead592
Exception stack trace: javax.naming.NoPermissionException: NO_PERMISSION
exception caught. Root exception is org.omg.CORBA.NO_PERMISSION: not
authorized to perform rebind_java_object operation. vmcid: 0x0 minor code:
0 completed: No
at
com.ibm.ws.naming.cosbase.WsnOptimizedNamingImplBase.performAuthorizationChe
ck(WsnOptimizedNamingImplBase.java:2808)
at
com.ibm.ws.naming.cosbase.WsnOptimizedNamingImplBase.rebind_java_object(WsnO
ptimizedNamingImplBase.java:1021)
at
com.ibm.WsnOptimizedNaming._NamingContextStub.rebind_java_object(Unknown
Source)
at
com.ibm.ws.naming.jndicos.CNContextImpl.cosRebindJavaObject(CNContextImpl.ja
va:3337)
at
com.ibm.ws.naming.jndicos.CNContextImpl.doRebind(CNContextImpl.java:2035)
at
com.ibm.ws.naming.jndicos.CNContextImpl.rebind(CNContextImpl.java:522)
at com.ibm.ws.naming.util.WsnInitCtx.rebind(WsnInitCtx.java:184)
at javax.naming.InitialContext.rebind(InitialContext.java:377)
at org.hibernate.util.NamingHelper.bind(NamingHelper.java:49)
at
org.hibernate.impl.SessionFactoryObjectFactory.addInstance(SessionFactoryObj
ectFactory.java:90)
at
org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:260)
at
org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1005)
at
com.acme.util.HibernateInitializer.<init>(HibernateInitializer.java:45)
at
com.acme.util.HibernateInitializer.<clinit>(HibernateInitializer.java:31)
at
com.acme.service.lookuplist.LookupListManagerBean.ejbCreate(LookupListManage
rBean.java:65)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85
)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:60)
at java.lang.reflect.Method.invoke(Method.java:391)
at
com.ibm.ejs.container.StatelessBeanO.<init>(StatelessBeanO.java:145)
at
com.ibm.ejs.container.CMStatelessBeanO.<init>(CMStatelessBeanO.java:53)
at
com.ibm.ejs.container.CMStatelessBeanOFactory.create(CMStatelessBeanOFactory
.java:40)
at com.ibm.ejs.container.EJSHome.createBeanO(EJSHome.java:704)
at com.ibm.ejs.container.EJSHome.createBeanO(EJSHome.java:791)
at
com.ibm.ejs.container.activator.UncachedActivationStrategy.atActivate(Uncach
edActivationStrategy.java:78)
at
com.ibm.ejs.container.activator.Activator.activateBean(Activator.java:519)
at
com.ibm.ejs.container.EJSContainer.preInvoke_internal(EJSContainer.java:2792
)
at
com.ibm.ejs.container.EJSContainer.preInvoke(EJSContainer.java:2503)
at
com.acme.service.lookuplist.EJSLocalStatelessLookupListManager_98f09269.getR
olenameOfUser(EJSLocalStatelessLookupListManager_98f09269.java:214)
at
com.acme.jsf.util.AuthorizationFilter.doFilter(AuthorizationFilter.java:124)
at
com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstance
Wrapper.java:132)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.
java:71)
at
com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispatch(
WebAppRequestDispatcher.java:1162)
at
com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch(WebAppReques
tDispatcher.java:676)
at
com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequest
Dispatcher.java:203)
at
com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward(WebAppInvoker.java:125)
at
com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker
.java:294)
at
com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocation(C
achedInvocation.java:71)
at
com.ibm.ws.webcontainer.cache.invocation.CacheableInvocationContext.invoke(C
acheableInvocationContext.java:116)
at
com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI(ServletReq
uestProcessor.java:186)
at
com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service(OSEListene
r.java:334)
at
com.ibm.ws.webcontainer.http.HttpConnection.handleRequest(HttpConnection.jav
a:56)
at
com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:652)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:458)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:912)

[Paul Ilechko]

Ben_ wrote:
> Hello,
>
> Platform: WAS-ND v5.1.1.5
>
> The following is seen in the logs and prevents the application from running.
>
> It seems Hibernate is not authorized to bind its Session object into the
> Namespace.

I doubt that it has anything specifically to do with Hibernate ... can
you explain exactly what scenario this error occurs in? It looks like
there's a web request which calls an EJB, from the trace you posted.

What do you mean by "prevents the application from running" ?

[Ben_]

> I doubt that it has anything specifically to do with Hibernate ... can
> you explain exactly what scenario this error occurs in? It looks like
> there's a web request which calls an EJB, from the trace you posted.

There is indeed an EJB module and a Web module.

As far as I can tell (I'm not the author, only the admin who inherited the
trouble and the duty to solve it :-), there is a Servlet Filter to make some
sort of authentication (it's not using the integrated J2EE security).

To authenticate the user, the Filter will lookup a Bean to access the
peristence store with Hibernate.

I'm not supecting Hibernate directly, because it seems that the same
application will sometimes run and sometimes not. I'm rather suspecting a
mis-configuration or a mis-coding (aka bug :-).

For example, reading some Hibernate stuff, I see the following:
"
4.8.2
Hibernate will automatically place the SessionFactory in JNDI after you call
cfg.buildSessionFactory().
(...)
4.8.3
For non-managed environments we suggested HibernateUtil with a static
SessionFactory, and ThreadLocal management of the Hibernate Session. This
approach isn't easy to use in an EJB environment, as several EJB's may
execute inside the same transaction but not the same thread. We recommend
that you bind the SessionFactory to JNDI in a managend environment.
"
(http://www.hibernate.org/hib_docs/v3/reference/en/html/session-configuratio
n.html)

This goes about transactions and threading, and this uses to ring a bell to
me, because I know weird things can happen here...

Could it be that the Session is initially bound in the JNDI by a thread with
"certain" permissions, and the web thread is then not authorized (not the
same permissions) to rebind it (I see "InitialContext.rebind()" in the
stacktrace) ?

So, the application woud sometimes run or not, depending on a race condition
?

> What do you mean by "prevents the application from running" ?

Application Server and Web Module start. But it's pretty useless, because
when attempting to enter the application, the exception interrupts the
authentication mechanism.

[Paul Ilechko]

Ben_ wrote:

>>I doubt that it has anything specifically to do with Hibernate ... can
>>you explain exactly what scenario this error occurs in? It looks like
>>there's a web request which calls an EJB, from the trace you posted.
>
>
> There is indeed an EJB module and a Web module.
>
> As far as I can tell (I'm not the author, only the admin who inherited the
> trouble and the duty to solve it :-), there is a Servlet Filter to make some
> sort of authentication (it's not using the integrated J2EE security).
>

You need to be an authenticated user to have write or create access to
the JNDI namespace (by default). If you've rolled your own security and
you're not integrating correctly with WAS security (and it sounds like
you're not) then you will be running as Unauthenticated as far as WAS is
concerned, so this could be the issue you're having. You can bypass this
by giving Cos Naming Write and Cos Naming Create privileges to Everyone,
but I wouldn't really recommend doing that, it leaves your namespace
wide open to be hacked by anyone capable of writing an IIOP client.

> To authenticate the user, the Filter will lookup a Bean to access the
> peristence store with Hibernate.

Don't know what influence you are able to have on your developers, but
if they want to use a database to store user authentication info rather
than the more common approach of using LDAP, the better way to handle
this is to develop a WAS Custom Registry on top of that database, which
will then allow you to integrate fully with WAS security and save you
having to re-invent it. Email me offline if you need further pointers on
this. (I don't mind helping a good newsgroup citizen like you, who often
helps others).

PAUL.

[Ben_]

> If you've rolled your own security and

Yes, definetly ad-hoc mechanism and not WAS security.

> you're not integrating correctly with WAS security (and it sounds like
> you're not) then you will be running as Unauthenticated as far as WAS is
> concerned, so this could be the issue you're having.

Even with credentials in soap.client.props ?

> You can bypass this
> by giving Cos Naming Write and Cos Naming Create privileges to Everyone,
> but I wouldn't really recommend doing that, it leaves your namespace
> wide open to be hacked by anyone capable of writing an IIOP client.

I wouldn't like to do this either.

> Don't know what influence you are able to have on your developers, but
> if they want to use a database to store user authentication info rather
> than the more common approach of using LDAP, the better way to handle
> this is to develop a WAS Custom Registry on top of that database, which
> will then allow you to integrate fully with WAS security and save you
> having to re-invent it.

Yes, from the InfoCenter samples it seems pretty straightforward, but
development is so close to production they are not likely to change the
security.

And, if I'm correct, the Custom User Registry is defined at the Cell level.
So, a concern is then that, since the Cell hosts many different
applications, probably not every application would want its own User
Registry, but there would be several ones in the Cell at least.

So, it would require a "super" Custom User Registry to be able to identify
in which application it's running and delegate the identification to the
application's Custom User Registry.

> Email me offline if you need further pointers on
> this. (I don't mind helping a good newsgroup citizen like you, who often
> helps others).

Thanks for the offer, I'll keep it in mind. And thanks for the compliment,
it's always a pleasure to receive credit from knowledgeable people.

>
> PAUL.
>
>
>

[Paul Ilechko]

Ben_ wrote:

>>you're not integrating correctly with WAS security (and it sounds like
>>you're not) then you will be running as Unauthenticated as far as WAS is
>>concerned, so this could be the issue you're having.
>
>
> Even with credentials in soap.client.props ?

This is only for admin clients (wsadmin) - has no relevance to accessing
applications.

> And, if I'm correct, the Custom User Registry is defined at the Cell level.
> So, a concern is then that, since the Cell hosts many different
> applications, probably not every application would want its own User
> Registry, but there would be several ones in the Cell at least.
>
> So, it would require a "super" Custom User Registry to be able to identify
> in which application it's running and delegate the identification to the
> application's Custom User Registry.

Yes. Are you hosting multiple applications for different companies in an
ASP type model, or are all these applications for the same organization?
If the latter, I would suggest it's definitely worth the effort to
develop a common registry and common security solution for the
enterprise, preferably based around open standards like LDAP and J2EE
security. If it's the former, you might not want to host the apps in the
same cell anyway.

[Paul Ilechko]

Ben_ wrote:

>>If you've rolled your own security and
>
>
> Yes, definetly ad-hoc mechanism and not WAS security.
>
>
>>you're not integrating correctly with WAS security (and it sounds like
>>you're not) then you will be running as Unauthenticated as far as WAS is
>>concerned, so this could be the issue you're having.
>
>
> Even with credentials in soap.client.props ?
>
>
>>You can bypass this
>>by giving Cos Naming Write and Cos Naming Create privileges to Everyone,
>>but I wouldn't really recommend doing that, it leaves your namespace
>>wide open to be hacked by anyone capable of writing an IIOP client.
>
>
> I wouldn't like to do this either.
>

Another alternative that a friend suggested .. you could use RunAs roles
for any EJB or Servlet components that need to bind to the namespace, so
that they would have some static identity and would not be unauthenticated.

[Ben_]

Hello,

Reading some stuff in the InfoCenter, I wonder the application is really
running as anonymous as you said and if using RunAs role is then necessary:
"
When global security is enabled, WebSphere Application Servers run under the
server identity that is defined under the active user registry
configuration. Although it is not shown on the administrative console and in
other tools, a special Server subject is mapped to the administrator role.
(...)
Additionally, a Server special-subject is assigned to all the four CosNaming
roles by default. The Server special-subject provides a WebSphere
Application Server server process, which runs under the server identity,
access to all the CosNaming operations. Note that the Server special-subject
does not display and cannot be modified through the administrative console
or other administrative tools.
"
http://publib.boulder.ibm.com/infocenter/wasinfo/v5r1//topic/com.ibm.websphe
re.zseries.doc/info/zseries/ae/csec_adminconsole.html

Thanks.

[Paul Ilechko]

Ben, this is for access to CosNaming by the application server code,
which runs in privileged mode. It doesn't apply to user code.

To follow up on my earlier post, I think the RunAs would solve your
problem, but you're probably going to need a user registry if you want
to be able to bind RunAs roles using the tooling (you might be able to
hack the binding files yourself, but it's probably ugly). The easiest
solution would be to configure WAS to use a file-based Custom Registry
(example in infocenter) which just contains a single "system user" for
this purpose. This shouldn't affect the applications in any way as they
are not using J2EE security and thus are not protected resources.

Paul.

[Ben_]

Hello,

I'll have a look at how to configure RunAs roles.

But does it require a Custom User Registry ? Global Security is enabled, so
there is a User Registry (LDAP). Only, it's not used because not all users
are in there. But, at least, there is the wasadmin user, so I could use it,
no ?

BTW, is there no means to give credentials somewhere ? Would
sas.client.props be of any help ?

Thx.

[Paul Ilechko]

Ben_ wrote:

> Hello,
>
> I'll have a look at how to configure RunAs roles.
>
> But does it require a Custom User Registry ? Global Security is enabled, so
> there is a User Registry (LDAP). Only, it's not used because not all users
> are in there. But, at least, there is the wasadmin user, so I could use it,
> no ?

OK, I got the impression from your earlier posts that WAS security was
not turned on. If it is, yes, you can use any user in the registry.

> BTW, is there no means to give credentials somewhere ?

That's what RunAs does.

> Would sas.client.props be of any help ?

Not for what you're trying to do. I think I mentioned early that this is
for admin clients only.

[Ben_]

> OK, I got the impression from your earlier posts that WAS security was
> not turned on. If it is, yes, you can use any user in the registry.

Yes, I forgot to mention Global Security is activated. Basically, to secure
the admin console only.

> > Would sas.client.props be of any help ?
>
> Not for what you're trying to do. I think I mentioned early that this is
> for admin clients only.
>

We had it over soap.client.props earlier. I don't know exactly the purpose
of sas.client.props. Hence my question. I'll check the InfoCenter.

Thx.

[Paul Ilechko]

Ben_ wrote:

>
> We had it over soap.client.props earlier. I don't know exactly the purpose
> of sas.client.props. Hence my question. I'll check the InfoCenter.

Sorry I misread - soap client props is for admin client;
sas.client.props is for java clients. Neither helps with web-based apps.