java.lang.SecurityException: Invalid Subject: principals on ic.lookup

[john hutchinson]

Weblogic 7.0.1

I establish two initialContext objects with credential like so:

InitialContext ic = getInitialContext("t3://<ip>:<port>", "<username>",
"<password>");
InitialContext ic2 = getInitialContext("t3://<sameip>:<differentport>",
"<username>", "<differentpassword>");

protected InitialContext getInitialContext(String url, String user, String
password) throws NamingException
{
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
env.put(Context.PROVIDER_URL, url);
env.put(Context.SECURITY_PRINCIPAL, user);
env.put(Context.SECURITY_CREDENTIALS, password);
return new InitialContext(env);
}

Each of these servers has a jms queue I want to context to. When I try to do
a lookup like this (ic):
qconFactory = (QueueConnectionFactory) ic.lookup("my/Queue");

I get this exception:

java.lang.SecurityException: Invalid Subject: principals=[system2, Administrators]
at weblogic.security.service.SecurityServiceManager.seal(SecurityServiceManager.java:943)
at weblogic.rjvm.MsgAbbrevInputStream.getSubject(MsgAbbrevInputStream.java:147)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:309)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)
End server side stack trace

Here is the bad issue. The second lookup works (ic2):
qconFactory = (QueueConnectionFactory) ic2.lookup("my/Queue");

As a matter of fact if I try to create more contexts the last context always seems
to work. Also if I do each of these lookups in a separate application they both
work. Any ideas?

[Tom Barnes]

As with all versions of WebLogic, the security context is
associated with the thread. So establishing a new one
will replace the previous context associated with
the thread. For more detailed information
post to the weblogic.developer.interest.security newsgroup.

Tom, BEA

[Tom Barnes]

Hi John,

There may be a bug, but the fact that some code works in a previous
version does not necessarily make this a given. For example, a new
release may restrict applications based on a refinement or clarification
in a J2EE spec. (Although in general, we try to make such changes
without breaking current customer code.) Another example is an
application that unknowingly depends on a bug that was in the previous
version. That said, this is unrelated to JMS, as the exception occurs
on a jndi lookup before any JMS code is invoked - I suggest posting to
the security newsgroup and perhaps raising the issue with customer
support.

Tom, BEA

john hutchinson wrote:
> The code below works with other versions of WebLogic. It just doesn't work with
> WebLogic7.0. I don't understand what one context object has to do with another.
> The code below indicates two different context object. I can also catch the
> exception when it is thrown re-establish the first context after the second works
> and use then use the first so that would be useless security. So either there
> is a bug in WebLogic's use of contexts or there is a bug in there security model.
> If it works I've attached a sample application that does this.

[Deyan D. Bektchiev]

John,
If you follow the instructions in this link you'll be able to solve your
issue.
http://edocs.bea.com/wls/docs70/adminguide/managetx.html#1050458

Regards,
Dejan

john hutchinson wrote:

>The code below works with other versions of WebLogic. It just doesn't work with
>WebLogic7.0. I don't understand what one context object has to do with another.
> The code below indicates two different context object. I can also catch the
>exception when it is thrown re-establish the first context after the second works
>and use then use the first so that would be useless security. So either there
>is a bug in WebLogic's use of contexts or there is a bug in there security model.
> If it works I've attached a sample application that does this.
>
>
>Tom Barnes <ple...@replyinnewsgroup.com> wrote:
>
>