we would like to secured EJB access in such a way, that even unauthenticated calls (principal=null) will be excuted with an assigned default principal and default role (which we need for an additional IsCallerInRole() based security test within the EJB method itself).
We setup the following chained login module configuration:
<!-- Chained Security Domain --> <application-policy name = "ChainedSecurityRealm"> <authentication> <!-- try authentication lookup user/roles in security database --> <login-module code = "org.jboss.security.auth.spi.DatabaseServerLoginModule" flag = "sufficient"> <module-option name = "dsJndiName">java:/SecurityDS</module-option> <module-option name = "principalsQuery">SELECT password FROM principals WHERE ....</module-option> <module-option name = "rolesQuery">SELECT role FROM roles WHERE ....</module-option> </login-module> <!-- fallback to DefaultPrincipal with role DefaultRole for unauthenticated callers --> <login-module code="org.jboss.security.auth.spi.IdentityLoginModule" flag="required"> <module-option name="principal">DefaultPrincipal</module-option> <module-option name="roles">DefaultRole</module-option> </login-module> </authentication> </application-policy>
If a caller cannot be authenticated by the first DatabaseServerLoginModule (sufficent), that a DefaultPrincipal with DefaultRole will always be assigned by the second IdentityLoginModule.
So far, so good, general authentication and authorization within the SecurityInterceptor of the EJB is propperly handled even for unauthenticated callers ( -> method access granted ).
Unfortunately within the method itself a call to Context.isUserInRole("DefaultRole") still returns false, as the principal element in the bean context is still null (originally set to null on invocation, as the client did not provided authentication information).
I would expect that the DefaultPrincipal and its DefaultRole should be assigned to the context principal element (which analogously happens for example in case of an explicit EJB role assignment via "run-as" tag)
Is this a bug or an expected behaviour ?