More SecurityDomain woes in AS5

[lhoriman]

I've created a simple test app with a DyamicLoginConfig mbean that loads an arbitrary config. This mbean is loaded from a jboss-service.xml located in the META-INF of the ear. The mbean seems to load just fine and the java:/jaas/blah domain is visible in JNDI.

However, attempts to actually use this security domain (by using the @SecurityDomain annotation on EJBs) fail. The container actually uses the "other" domain no matter what I do. When I make unauthenticated calls, the identity returned by getPrincipal() is the unauthenticated identity of "other".

Authenticated calls using the LoginInitialContextFactory completely fail on the client, just throwing java.lang.ClassNotFoundException: com.sun.security.auth.login.ConfigFile. Manually setting up the identity with SecurityAssociation.setPrincipal() and setCredential() have no effect.

Do remote calls to protected EJBs work at all?

Jeff

[jaikiran]

However, attempts to actually use this security domain (by using the @SecurityDomain annotation on EJBs) fail. The container actually uses the "other" domain no matter what I do.

Please post the entire exception stacktrace, the bean code with the SecurityDomain annotations and even the import statement in the bean code. Also enable TRACE level logging on jboss security package and post them here. See this wiki (Q4) for enabling TRACE level logging of security package http://www.jboss.org/community/docs/DOC-12198

While posting logs or xml content or code, please remember to wrap it in a code block by using the Code button in the message editor window. Please use the Preview button to ensure that your post is correctly formatted.

[wolfgangknauf]

Hi Jeff,

which JBoss version do you use?

For 5.0, the login by InitialContext access is no longer supported, you have to perform a JAAS login.

AppCallbackHandler callbackHandler = new AppCallbackHandler("user", "password");
 LoginContext loginContext = new LoginContext ("loginconfigname", callbackHandler);
 loginContext.login();
 ....

For this to work, you will require an "auth.conf" file.

I think there is a simpler approach using some class "SecurityClient", but I don't find doc for this ;-).

Best regards

Wolfgang

[jaikiran]

Ah, i did not pay attention that the original poster was using programmatic login. Thanks Wolfgang for pointing that out :)

"Wolfgang Knauf" wrote:

I think there is a simpler approach using some class "SecurityClient", but I don't find doc for this ;-).

Best regards

Wolfgang

Here you go http://www.jboss.org/file-access/default/members/jbossejb3/freezone/docs/tutorial/1.0.3/html/Security_and_Transactions_in_EJB3.html

And the entire downloadable source code is available here http://www.jboss.org/jbossejb3/docs/

[lhoriman]

"jaikiran" wrote:
Here you go http://www.jboss.org/file-access/default/members/jbossejb3/freezone/docs/tutorial/1.0.3/html/Security_and_Transactions_in_EJB3.html

Thanks, that sorted out the remote client problem.

It appears that the other problem is related to the fact that just about everything related to @Service beans is broken. The start() method executes in the context of the "other" security domain (no matter what @SecurityDomain says), @RunAs doesn't work in the start() method, and transactions are not created for the start() method.

This all worked in 4.x.

Jeff

[jaikiran]

"lhoriman" wrote:
The start() method executes in the context of the "other" security domain (no matter what @SecurityDomain says), @RunAs doesn't work in the start() method

That has been taken note of in your other post here http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151142