Question on Default JBoss Security

[ftg314159]

The JBoss 3.2 Admin Guide does a great job of explaining JAAS, but my question deals with the default security within the JBoss server "out of the box".

Could someone please describe how JBoss creates any Subjects and Principals it uses internally, and where it gets the information from ?

This question has nothing to do with client login. I understand that client login involves using a JAAS plugin which obtains information from the client. However, just in being brought up, the JBoss server seems to be working with Subjects and Principals. I imagine that the data for these comes from the XML configuration files, but I can't find any docs on where.

A JBoss build will come up on Linux out-of-the-box, but on z/OS it finds that needed Subjects and Principals are null. I'm guessing that somehow the default JBoss configuration files trace down to Userids which are defined on the Linux system, but not on z/OS.

Can anyone point me to the pertinent configuration files and an explanation of their relationship to and requirements from the underlying platform ?

[juha]

The subject is populated based on the roles found from your configured LoginModule on the server side.

By default there are no configured security domains.

There's no access to the underlying OS user IDs.

-- Juha

[ftg314159]

Um, OK, I'm not sure where to take this from here. How can I diagnose why the same JBoss code runs on one system but not another, when it says that the problem is that it's finding a null principal on one system and not on another ?

I assume you're talking about the login-config.xml file. The only reason I can think of why this would make a difference on z/OS would be if the file was being read by something which assumed that it was in the platform-default encoding (EBCDIC) rather than the ASCII or UTF-8 form expected by XML parsers. All of the other XML config files seem to be processed correctly when left in UTF-8 on z/OS.

It's the same login-config.xml file on each system.

Thanks for any help. I really need to get this to work.

[juha]

Please post some more server log or stack trace, which service exactly is failing to authenticate? Is it the JMS persistence manager?

-- Juha

[ftg314159]

I'm attaching a log with full DEBUG enabled. The failing component does appear to be the persistence manager, and the stack trace exception is down towards the end of the file. This is 3.2.1, and the login config is the version distributed in the download.

Thanks for your help on this.

[juha]

You could try asking/searching on the JMS forum, someone might have seen this issue before.

Are both Linux and z/OS on IBM VM?

[ftg314159]

No, the Linux case is native on a PC, and the z/OS case is native on a z/OS machine.

I'll do that (check JMS forum), thanks. My other thought was to put debugging code into the Linux case, see what the subject/principal is at the point where the z/OS case fails, and then try to figure out who sets them. With any luck, comparing the Linux and z/OS cases might point out the problem.

Would you be able to give me a description of the code path or a list of the code areas which are supposed to be involved in getting the missing principal set by the time the failing code is trying to find it ?

Thanks again for your time on this.

[ftg314159]

Hmm.. good call on the JMS forum. I found message 380261 indicating that this can be a problem in the login-config stuff associated with Hypersonic, since JMS uses that to store persistence state. The poster wasn't using z/OS, but had the same null principal problem.

I'll investigate and let you know if I need any further assistance.

Thanks.

[ftg314159]

I've dug into this a bit further, and it *does* appear to be a security problem.

Referring to the previously posted stacktrace, the problem surfaces in BaseConnectionManager2.getSubject(), when a call to securityDomain.isValid() fails.

I placed some debugging code, and found that securityDomain is an instance of JaasSecurityManager, so I placed debugging code there and found that the isValid() call fails because its call to JaasSecurityManager.authenticate() fails. The authenticate() call fails because its LoginContext.login() call is throwing a LoginException, which is being swallowed by some catch{} code which says "Don't log anonymous user failures unless trace level logging is on".

The exception, captured when it occurs, is:
16:19:28,280 ERROR [STDERR] javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.resource.security.ConfiguredIdentityLoginModule
16:19:28,280 ERROR [STDERR] at javax.security.auth.login.LoginContext.invoke(LoginContext.java:643)
16:19:28,281 ERROR [STDERR] at javax.security.auth.login.LoginContext.access$000(LoginContext.java:124)
16:19:28,281 ERROR [STDERR] at javax.security.auth.login.LoginContext$3.run(LoginContext.java:543)
16:19:28,282 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method)
16:19:28,282 ERROR [STDERR] at javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:540)
16:19:28,283 ERROR [STDERR] at javax.security.auth.login.LoginContext.login(LoginContext.java:450)
16:19:28,283 ERROR [STDERR] at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:473)
16:19:28,283 ERROR [STDERR] at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:425)
16:19:28,284 ERROR [STDERR] at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:249)
16:19:28,287 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnectionManager2.getSubject(BaseConnectionManager2.java:663)
16:19:28,287 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:488)
16:19:28,287 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:804)


I have no idea why it can't find this class, because it is present in the jboss-jca.sar archive in $JBOSS_DIST/server/default/deploy/.

Under Linux, it finds it with no problem.

The major difference between Linux and z/OS is that the JDK on Linux is IBM 1.4, while on z/OS it is IBM 1.3.

There is probably also some difference if the execution flow is getting to any underlying IBM JAAS code. IIRC IBM sort of invented JAAS to match the z/OS RACF security model, and donated it back to Java, so there could be some mismatch here, but my impression was that JBoss carries its own javax.security JARs, so there really isn't any reason for control to leave the JBoss-provided JARs.

This smells like some sort of classloader problem, but since I don't have source for the javax.security classes, I can't really pursue it.

Any ideas on how to proceed would be very much appreciated.

[ftg314159]

All right, I've gotten to the bottom of this. I've even gotten JBoss to initialize without the Exception. But I did it with an ugly hack, and I'm not sure what the JBoss team would want to do instead.

The problem is that IBM's z/OS JVM comes with its own JAAS classes in $JAVA_HOME/lib/ext which are overriding the replacements supplied by JBoss in jboss-jaas.jar. Specifically, the JBoss LoginContext talks about adding support for classloaders, and the lack of that support seems to be why the IBM classes can't find the LoginModules defined in the JBoss login-config.xml.

I got around this by using -Xbootclasspath/p: to prepend the needed JBoss JARs to the boot classpath. However, it wasn't just jboss-jaas.jar, but any other JAR it referenced, including jboss-common.jar, log4j-boot.jar, and xml-apis.jar.

As I've said, this is a 1.3.1 JVM, so JAAS isn't built-in. And, when I used to run 1.3.x on Linux with JBoss, the JVM probably didn't have any competing JAAS classes of its own. What I don't understand is why this doesn't cause a problem under 1.4, where JAAS is supposed to be part of the JVM. Shouldn't the 1.4 JVM classes be pre-empting the JBoss versions ?

In any case, the hack I'm using doesn't have much longevity. I'd really like to see some feedback from the JBoss team as to how they want to proceed in environments where the bootclasspath has classes which compete with JBoss-provided ones.

[juha]

The recommendation is to keep your boot classpath clean, including the classes from lib/ext. There's no way we can work around the system classloader (especially in 1.3 -- 1.4 allows this to be overridden, whether it includes classes from lib/ext or if those get added into the primordial classloader I'm not sure).

As for the JAAS classloading problem, IIRC previous versions of JAAS required all LoginModule implementations to be present in system classpath. This doesn't work well from JBoss point of view. From the sound of your description, it might be that this issue has been fixed in more recent (IBM?) JAAS implementations.

-- Juha