How to set EJBContext callerPrincipal from LoginModule?

[bhawthorne]

We've just migrated our app to JBoss 5 (from 4) and have one last annoyance to resolve. We have an EJB client that uses JNDILoginInitialContextFactory to supply string-based user/password combination. On the server, our custom JAAS login module authenticates, and sets our custom Principal to the group "CallerPrincipal" according to spec. EJBs then see this custom principal in the EJBContext just fine.

With JBoss 5, this no longer works. As I understand, with JBoss 5 we have to perform a SecurityClient login now, and obtain the InitialContext with a NamingContextFactory instead.

 SecurityClient client = SecurityClientFactory.getSecurityClient();
 client.setSimple("jdoe", "theduke");
 client.login();

 Properties p = new Properties();
 p.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
 p.put(Context.PROVIDER_URL, "jnp://localhost");
 p.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");

 InitialContext initialContext = new InitialContext(p);

Upon doing so, authentication succeeds, but the EJBContext seems to only get populated with a SimplePrincipal. I narrowed it down a bit and found that the EJBContext is populated with the principal as it is supplied to the SecurityClient. If I set a test custom principal on the SecurityClient

client.setSimple(new CustomPrincipal("jdoe"), "theduke");

it is propagated to the EJBContext, but this is not a solution, our actual custom principal (User object) is not yet available to the client and cannot be retrieved pre-login.

So how is one supposed to establish a custom callerPrincipal via LoginModule in JBoss 5 now?

Thanks in advance.

[abille]

Hello bhawthorne,

well, we faced the same problem currently and found, that even writing of a own login module setting the custom principal into the subject does not succeed - using sessionContext.getCallerPrincipal returns an instance of SimplePrincipal.

This is very annoyning, meaning that there is apparantly some code in JBoss, which takes the name of the custom principal and uses it to construct a simple principal.

I would be glad to here that my findings are incorrect or that there is a workaround other than using the custom principal simply as wrapper ...

[bhawthorne]

Thanks for your reply. Since no one here seems to know anything about it, I will look into filing a bug report.

[leobaz2]

I have the exact same problem. I am trying to debug jboss to see what is going on. Does anyone know where I can get the source for jbosssx? It doesn't seem to be in the jboss source I downloaded.

[leobaz2]

I'm not sure if you created the bug yet but here is what I found:

When you log in to a web app:
1) In JBossWebRealm.authenticate, a SimplePrincipal is created with the username (line 382).
2) This SimplePrincipal is passed to SecurityAssociationActions.setPrincipalInfo on line 388 of JBossWebRealm.
3) The SimplePrincipal gets passed through to SubjectInfo constructor line 56. At this point, we have the SimplePrincipal and the Subject which contains the custom principal.
4) Here, a CredentialIdentity is created which holds the SimplePrincipal. This CredentialIdentity is not passed the subject so the custom principal is lost at this point.

Later on the explicit call to getCallerPrincipal() in your EJB will invoke JBossSecurityContextUtil.getUserPrincipal. This will get the SubjectInfo and get the identity of type CredentialIdentity. From step 4 above, the identity of type CredentialIdentity will only contain the SimplePrincipal. That sums it up.

I don't see any way we can currently get back the custom principal without a code change.

[leobaz2]

I guess the difference between jboss 4 and 5 is that in jboss 4, the "CallerPrincipal" will used to determine the principal to return. For jboss 5, it returns the identity of type CredentialIdentity.

[anil.saldhana]

This seems to be a bug.

https://jira.jboss.org/jira/browse/JBAS-6593

Is this for EJB2 or EJB3?

[bhawthorne]

EJB 3

[anil.saldhana]

https://jira.jboss.org/jira/browse/EJBTHREE-1756

This bug has been moved to the EJB3 project.

Please add yourself as a watcher on this bug. You can also vote on it.

[cimershein]

Is there any progress / status on this bug?

I have voted and "watched" it in JIRA, but haven't seen any comments or work yet.

Is it confirmed that this is a bug and not a configuration issue? (Any other configuration tips to try to work around it?)

Any chance of getting the bug onto the road map for a possible future fix version? It seems like it is pretty major and might be affecting many users (although they may not know about the specific JIRA bug to vote/watch it).

Thanks,

Chris

[bbunderson]

Not having access to a custom principal is big problem for us. I posted a comment to the JIRA issue (two actually, sorry, browser wierdness) and I also voted on the issue.

I'm not sure how to work around this other than to write some sort of interceptor to basically do the work that I wanted to do in my custom LoginHandler.

Does anyone out there have a suggested work around for this problem?

[bhawthorne]

"bbunderson" wrote:

Does anyone out there have a suggested work around for this problem?

Unholy access via reflection. This works for us:

Field rmField = EJBContextImpl.class.getDeclaredField("rm");
rmField.setAccessible(true);
RealmMapping rm = (RealmMapping)rmField.get(ejbContext);

Principal callerPrincipal = ejbContext.getCallerPrincipal();
CustomPrincipal customPrincipal = (CustomPrincipal)rm.getPrincipal(callerPrincipal);

[bbunderson]

rmField.setAccessible(true)? Yes, a little bit of my soul died typing that in but it works. Thank you very much for the help.

[pepez]

I have similar problem, added a question to stackoverflow:
http://stackoverflow.com/questions/1295938/jaas-and-jboss-5-problem-with-principal

The reflection example works but I would prefer ... hmm... different solution.

Also watching and voted that bug.

[hosier.david]

I got this idea from the FAQ that is listed in the sticky post at the top of this forum, and it worked for me. This idea presumes that the recommendation is followed to create a CallerPrincipal group in getRoleSets() and add your custom principal as a member of that group.

 Principal callerPrincipal = null;
 try {
 Subject caller = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container");
 for (Principal p : caller.getPrincipals()) {
 if (p.getName().equals("CallerPrincipal")) {
 Group g = (Group)p;
 callerPrincipal = g.members().nextElement();
 }
 }
 } catch (Exception e) {
 log.error("Error accessing Subject", e);
 }

Obviously the code could be enhanced to recognize whatever groups you might use or to check the Principal type instead of just assuming there is one principal in a specific group.