#104 WebLogic: connect to remote srvr fails w/ security exception
Logging the issue as reported by David Karr.
---------------
I work on a Spring 1.2.8 application that we deploy to
WebLogic 8.1.4.
I implemented the Spring registration code (XML) to
register my beans.
I had to write a custom MBeanExporter using Commons
Modeler because the
default bean registration process won't work with
Spring beans in
WebLogic 8.1.4 (the beans end up in a classloader
inaccessible to the
mbeanserver).
I deployed this code to my laptop WebLogic server, and
used Jmanage1.5b
to connect to it. It works perfectly fine.
I then had my code deployed to our integration server
on a Unix box.
When I try to connect to it from JManage1.5b, it fails
(it just says
"connection to the application failed").
After digging in my server log, I saw an error like this:
----------------------
####<Oct 27, 2006 4:22:03 PM CDT> <Warning> <RMI>
<apps489> <EAI_DEV>
<ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'>
<<WLS Kernel>>
<> <BEA-080003> <RuntimeException thrown by rmi server:
weblogic.rmi.internal.BasicServerRef@101 -hostID:
7514024937243625124S:10.96.11.61:[8500,8500,-1,-1,8500,-1,-1,0,0]:uia2:E
AI_DEV', oid: '257', implementation: 'MBeanHomeImpl for
server EAI_DEV'
java.lang.SecurityException: [Security:090398]Invalid
Subject:
principals=[weblogic, Administrators].java.lang.Throwable:
[Security:090398]Invalid Subject: principals=[weblogic,
Administrators]
at
weblogic.security.service.SecurityServiceManager.seal(SecurityServiceMan
ager.java:697)
at
weblogic.rjvm.MsgAbbrevInputStream.getSubject(MsgAbbrevInputStream.java:
190)
----------------------
Someone on the dev2dev forums had already seen this
problem, and they
reported the problem to BEA. I'm going to include the
information they
received here, to see if it's possible to fix Jmanage
to deal with this.
---------------------------------------
/**
* For cases where we loose the connection to weblogic,
we put a
validation in here,
* so we can reconnect when necessary. It appears that
the session goes
stale on
* weblogic, and we need to reconnect when this happens.
*
*/
public MBeanServer getMBeanServer() {
try {
// simply see whether we can get the count of MBeans as
a test to check
our credentials, to make sure we're still valid.
super.getMBeanServer().getMBeanCount();
} catch (SecurityException ex) {
logger.info("lost security context for connection to " +
getProxyConfiguration().getServerURL() + ",
reconnecting...");
try {
MBeanHome home =
Helper.getMBeanHome(getProxyConfiguration().getRole(),
getProxyConfiguration().getPassword(),
getProxyConfiguration().getServerURL(),
getProxyConfiguration().getObjectGroupName());
super.setMBeanServer(home.getMBeanServer());
logger.info("reconnected to: " +
getProxyConfiguration().getServerURL());
}catch(Exception nex) {
logger.error(nex);
}
}
return super.getMBeanServer();
}
>From : Alper Akture (alper.akture@intersperse.com)
Date : 07/28/2006 10:26:07 AM
Subject : RE: BEA Support Case: 662793
To : BEA Customer Support
CC List : Mark Thomsen
Hello Raghu,
It appears that catching the exception and reconnecting
fixes the issue.
I have a little more testing to do, but so far it seems
fine. Thanks for
you help!
Alper
===========================================================
From: Raghavendran - BEA Systems
Date: Jul-25-2006 14:38 GMT-08:00
Activity: Email Log Added
Sent to: [alper.akture@intersperse.com]
Alper,
You are correct. The security context is still there
but stale. Weblogic
authenticates a principal and creates an authenticated
subject.
Once the authentication is done, to avoid doing
authentication
everytime, it seals the authenticated subject.
If the thread access a remote JVM or a different
resource or if the
thread is idle for some time, the seal will be broken
or invalid.
When the thread accesses the protected resource next
time, weblogic will
try to authenticate and re-create the seal again.
This is the reason you see:
java.lang.SecurityException: [Security:090398]Invalid
Subject:
principals=[weblogic, Administrators]
at
weblogic.security.service.SecurityServiceManager.seal(SecurityServiceMan
ager.java:680)
It is best to handle such scenario by recreating the
context.
-Raghu
BEA Support
=============================================================
>From : Alper Akture (alper.akture@intersperse.com)
Date : 07/25/2006 09:21:46 AM
Subject : RE: BEA Support Case: 662793
To : BEA Customer Support
CC List : Mark Thomsen
Hi Raghu,
Thanks for the suggestion. I will try it out, but it
will require some
refactoring of the code, so I will try to get to it
later this week. One
thing however, in the trace on the server, it does
output the user:
java.lang.SecurityException: [Security:090398]Invalid
Subject:
principals=[weblogic, Administrators]
so it seems that it does have the security context maybe?
However, I will try your suggestion and let you know
the results.
Thanks,
Alper
FR: rsomasun
CASE_ID_NUM: 662793
CASE TITLE: JMX Security - After getting a
RemoteMBeanServer,
authentication will fail later
MESSAGE:
Hi Alper,
I am Raghu from BEA Support. Your support case 662793
has been
reassigned to me.
I went through the stack trace. I am yet to look into
the code.
It appears that you are spawning thread. Security
context is associated
with the thread that obtained initial context.
Ideally, if you are using the same thread to hit the
server you should
not get the security exception.
My gut feeling is that, the thread has lost the
security context before
accessing WeblogicMBeans.
Or, the thread that initially obtained the initial
context is different
from the one that is throwing the exception.
Can you catch the security exception and recreate the
initial context
and try the test again?
Thanks
Raghu
BEA Support
---------------------------------------
Logged In: YES
user_id=308349
I see that in the current code in the HEAD,
JMXHelper.getMBeanServer() is a static method, and it
returns a static MBeanServer object. I guess what they're
saying here is that the static mbeanserver can get into a
bad state, so it's unusable. The fix has to detect this
condition, or perhaps always return a new mbeanserver.
Logged In: YES
user_id=1058292
This issue was also reported as the following bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=1517401&group_id=111374&atid=659057
Logged In: YES
user_id=308349
I've found a fix for this problem, but I'm not sure whether
this will cause side-effects (like a memory leak).
In
"org.jmanage.core.modules.weblogic.WLServerConnectionFactory.findExternal()",
after obtaining the Context and then the MBeanHome, it
closes the context. This works fine when connecting to a
local server, but for some reason the "close()" call is an
issue with the remote server. When I removed the "close()"
call, I had no trouble connecting and using my remote server.
Logged In: YES
user_id=1058292
Originator: YES
Fixed for 2.0 beta release:
RCS file: /cvsroot/jmanage/jmanage/modules/weblogic/src/main/java/org/jmanage/core/modules/weblogic/WLServerConnection.java,v
retrieving revision 1.4
diff -r1.4 WLServerConnection.java
17a18,20
> import java.io.IOException;
> import java.util.logging.Logger;
>
20a24
> import org.jmanage.core.util.Loggers;
22a27,28
> import javax.naming.Context;
> import javax.naming.NamingException;
33a40,41
> private static final Logger logger = Loggers.getLogger(WLServerConnection.class);
>
34a43
> private final Context ctx;
36c45
< public WLServerConnection(MBeanServer mbeanServer){
---
> public WLServerConnection(MBeanServer mbeanServer, Context ctx){
39a49,61
> this.ctx = ctx;
> }
>
> /**
> * Closes the connection to the server
> */
> public void close() throws IOException{
> try {
> ctx.close();
> }
> catch (NamingException e) {
> logger.warning("Error closing context:" + e.getMessage());
> }
===================================================================
RCS file: /cvsroot/jmanage/jmanage/modules/weblogic/src/main/java/org/jmanage/core/modules/weblogic/WLServerConnectionFactory.java,v
retrieving revision 1.2
diff -r1.2 WLServerConnectionFactory.java
24d23
< import javax.naming.NamingException;
44,46c43,54
< MBeanHome home = findExternal(config.getURL(), config.getUsername(),
< config.getPassword());
< return new WLServerConnection(home.getMBeanServer());
---
> Hashtable<String, Object> props = new Hashtable<String, Object>();
> props.put(Context.INITIAL_CONTEXT_FACTORY,
> "weblogic.jndi.WLInitialContextFactory");
> props.put(Context.PROVIDER_URL, config.getURL());
> props.put(Context.SECURITY_PRINCIPAL, config.getUsername());
> props.put(Context.SECURITY_CREDENTIALS, config.getPassword());
> Context ctx = new InitialContext(props);
> MBeanHome home = (MBeanHome) ctx.lookup(MBeanHome.JNDI_NAME + "." +
> "localhome");
> // Fix for 1586075: Passing context in, so that it can be closed when the connection
> // is closed
> return new WLServerConnection(home.getMBeanServer(), ctx);
51,69d58
<
< private static MBeanHome findExternal(String url,
< String username,
< String password)
< throws NamingException {
<
< Hashtable<String, Object> props = new Hashtable<String, Object>();
< props.put(Context.INITIAL_CONTEXT_FACTORY,
< "weblogic.jndi.WLInitialContextFactory");
< props.put(Context.PROVIDER_URL, url);
< props.put(Context.SECURITY_PRINCIPAL, username);
< props.put(Context.SECURITY_CREDENTIALS, password);
< Context ctx = new InitialContext(props);
< MBeanHome home = (MBeanHome) ctx.lookup(MBeanHome.JNDI_NAME + "." +
< "localhome");
< ctx.close();
< return home;
< }
<
Logged In: YES
user_id=308349
Originator: NO
I've confirmed jmanage-2.0 beta connects successfully to both a local and remote WLS 8.1 server.
Has anyone ever submitted an enhancement request to have the application detect when an external jar has not been installed into the modules directory that is needed for proper operation? I thought it was still broken, until I realized I hadn't copied in the weblogic.jar file, and then it worked fine.
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 30 days (the time period specified by
the administrator of this Tracker).