Authentication succeeded, getCallerPrincipal()=anonymous

[zour]

I'm using JBoss 5.1.0, a J2EE application, the frontend is a RAP application
deployed in an OSGi container (Equinox). All runs fine beside the login.

Though authentication is successfull, I always get the default identity
anonymous from an EJB. Login does work properly, since if I enter a
wrong password I get redirected to the according web page.

@SecurityDomain("myapplication")
@Stateless(name = UserBean.EJBNAME)
public class UserBean implements UserBeanRemote, UserBeanLocal {

 public static final String EJBNAME = "UserBean";

 @Resource()
 private transient SessionContext session;

 @Override
 public void testSession() {
 String name = this.session.getCallerPrincipal().getName();
 System.out.println("Principal: "+name);
 }

The principal's name is always 'anonymous' (the default).

The custom login module is being used in other J2EE applications without
such problems. Snippet from login-config.xml:

<application-policy name="myapplication">
 <authentication>
 <login-module code="com.mypackage.ejb.jaas.AuthenticatorLoginModule" flag="required">
 <module-option name="authenticatorJndiName">MyApplication/AuthorizationBean/local</module-option>
 </login-module>

 <login-module code="org.jboss.security.ClientLoginModule" flag="required" />
 <authentication>
<application-policy>

web.xml:

<login-config>
 <auth-method>FORM</auth-method>
 <form-login-config>
 <form-login-page>/login.html</form-login-page>
 <form-error-page>/login_failed.html</form-error-page>
 </form-login-config>
</login-config>

jboss-web.xml

<jboss-web>
 <security-domain>java:/jaas/myapplication</security-domain>
</jboss-web>

jbossweb.sar/contex.xml

<Context cookies="true" crossContext="true">
<Manager pathname="" />
<InstanceListener>org.jboss.web.tomcat.security.RunAsListener</InstanceListener>
<Valve className="org.apache.catalina.authenticator.FormAuthenticator" characterEncoding="UTF-8" />
</Context>

I don't know if this is a bug or I'm just missing some configuration.
A Realm perhaps? Would this work: http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#JAASRealm

I have another working authorization configuration with JAAS and Seam,
but this doesn't require any Realm's at all.

Could you please give me a hint?

[zour]

It doesn't work with the UsersRolesLoginModule either.

<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
 <module-option name="unauthenticatedIdentity">anonymous</module-option>
 <module-option name="usersProperties">props/users.properties</module-option>
 <module-option name="rolesProperties">props/roles.properties</module-option>
</login-module>

Any ideas?

[wolfgangknauf]

Hi,

no ideas, but a lot of requests for more details ;-).

How does your client access your secured app? Is it a standalone application client? Is some servlet/website/web service called? How does the client log in?

Best regards

Wolfgang

[zour]

> How does your client access your secured app?

FarmerBeanRemote farmerBean = UserSession.getInstance(getShell().getDisplay()).getMasterDataServices().locateFarmerBean();
try {
 farmerBean.setAnything(this.actor, id);
} catch (Exception ex) {
 throw new RuntimeException(ex);
}

Obtaining of RAP client's user session:

public static UserSession getInstance(Display display) {
 return SessionAccessRunner.getUserSession(display);
}

Bean lookup:

public FarmerBeanRemote locateFarmerBean() {
try {
 Object objRef = getInitialContext().lookup(FARMER_BEAN);
 return (FarmerBeanRemote) PortableRemoteObject.narrow(objRef, FarmerBeanRemote.class);
} catch (Exception ex) {
 throw new RuntimeException("Failed to lookup FarmerBean: " + ex.getMessage(), ex);
 }
}

The lookup does work, as well as using methods from that bean.
Yet the injected SessionContext isn't aware of the login process.

> Is it a standalone application client

It is a RAP-Client (Rich Ajax Platform) deployed to JBoss. Practically it's running inside a JVM on the server. But any UI elements are rendered in an internet browser (using qooxdoo Javascript-Engine). It's RCP for the web browser.

> Is some servlet/website/web service called?

As far as I understand, a component called ServletBridge does this:
"org.eclipse.equinox.servletbridge.http:
Hooks back into the servlet bridge and proxies requests through to the servlet container to provide an OSGi Http Service."

> How does the client log in?

Via a webpage (login.html) before the RAP-Application starts, see web.xml above.

Maybe this isn't all about JBoss Security, but has something to do with how RAP handles requests, as I found here:
http://dev.eclipse.org/newslists/news.eclipse.technology.equinox/msg04603.html

[wolfgangknauf]

Hi,

thanks for the detailed answers to ALL my questions ;-). That's good forum style!
I hope my questions are not too silly, but I know only JBoss security a bit, but not RAP etc.

So the RAP AJAX part is running in the same JBoss as the web pages and the EJBs? Are the AJAX servlets secured the same way as your web pages (included in the "web-resource-collection" of the "security-constraint" in web.xml)? I hope that the AJAX call contains the session id so that the server uses the same session?

Best regards

Wolfgang

[zour]

RAP is running in the same JBoss and the access is restricted through:

<security-constraint>
 <web-resource-collection>
 <web-resource-name>myapplication</web-resource-name>
 <url-pattern>/test/*</url-pattern>
 </web-resource-collection>
 <auth-constraint>
 <role-name>*</role-name>
 </auth-constraint>
</security-constraint>

The RAP part work's fine. It seems I've found a solution to my problem:

http://msikora.typepad.com/michael_sikora_on_java_ee/2009/03/converting-to-jboss500ga-ejb3-security.html

I need to test this on a server so I can access from different client computers. For now, the authentication works. The SessionContext.getCallerPrincipal().getUsername() returns what I put in.

[geturner]

Was this ever solved?  I have EXACTLY the same situation, except the RAP code is deployed in WildFly.  We are using CLIENT_CERT and the audit log shows the user access to the WAR is valid and has the correct roles, but when an EJB is accessed, no security context exists and the principal is anonymous.