-
1. Re: EJB remote call does not propagate security principal
jaikiran Jun 17, 2012 11:01 PM (in response to dweil)Dirk Weil wrote:
I'm using JBoss 7.1.1.Final out-of-the-box, i.e. without any modifications of standalone.xml with regard to security. The ejb is called via the remote: protocol and userid and password are passed as properties when initializing the JNDI context.
Can you please post the relevant code?
Dirk Weil wrote:
a) Should you stay with ApplicationRealm or are you supposed to create a different realm for every application? If so, how do you specify the reals to use on client side?
The ApplicationRealm should be fine.
Dirk Weil wrote:
c) Are there some magic properties to pass from client to server to enable security principal propagation?
The presence of username, password or callbackhandler class names should be enough for security propagation.
Dirk Weil wrote:
d) Does ejb security work in WAR/EAR deployments only or can you use EJB-JAR files as well?
The packaging type does not matter. So yes, it works with WAR/EAR too.
-
2. Re: EJB remote call does not propagate security principal
dweil Jun 18, 2012 12:40 PM (in response to jaikiran)Jaikiran,
thank you very much for your quick answer. I've put together a small maven project reproducing the problem - well, nearly ... (jboss7remoteEjb.zip attached to discussion).
I use a vanilla JBoss 7.1.1 with configuration standalone-full.xml and just two users added to ApplicationRealm (via add-user.bat):
- User "anonymous", password "anonymousanonymous", role "guest"
- User "baselibsTestuser1", password "pwd4baselibsTestuser1", role "baselibsTestrole1"
After deploying the ejb jar file produced by the build the unit test UserInfoTest calls the ejb UserInfoBean (via remote:) and requests the server side user id. This is done with the two different user names mentioned above, but the returned user id is always "anonymous".
jboss7remoteEjb.zip builds an ejb jar. In my previous post I was using the same ejb inside a WAR deployment, where the additional descriptor jboss-web.xml requests application wide security:
<jboss-web>
<security-domain>other</security-domain>
</jboss-web>
In that szenario the user id returned by the ejb method is "$local" instead of "anynomous".
-
3. Re: EJB remote call does not propagate security principal
wdfink Jun 18, 2012 3:25 PM (in response to dweil)HI Dirk,
I suppose you hit the same trap as me.
If you are on the same server "$local" is the representation of an anonymous user.
If you use EAP6 or AS7.1.2 you will find an element
<local default-user="$local" />
within the security-realm. If you remove that the user will work as expected.
In AS7.1.1 I did not found that either so I suppose it is hardcoded here.
maybe we can have a discuss tomorrow "Treffpunkt Arminius"
-
4. Re: EJB remote call does not propagate security principal
jaikiran Jun 19, 2012 12:45 AM (in response to wdfink)Wolf-Dieter Fink wrote:
In AS7.1.1 I did not found that either so I suppose it is hardcoded here.
The ability to specify a different user than the default $local (which by the way is not an expression or system property), for silent authentication, was added after AS 7.1.1 was released https://issues.jboss.org/browse/AS7-4487, so it's not available in 7.1.1
-
5. Re: EJB remote call does not propagate security principal
dweil Jun 20, 2012 2:02 AM (in response to jaikiran)I tried the same on JBoss 7.2.0.Alpha1-SNAPSHOT with identical results, even after removing the "<local default-user="$local" />" from the security realm.
-
6. Re: EJB remote call does not propagate security principal
jaikiran Jun 20, 2012 2:15 AM (in response to dweil)Try adding these 2 properties to your JNDI properties:
jndiProps.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS", "JBOSS-LOCAL-USER");
jndiProps.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", false);
Let us know how that goes. I think there might be an issue in remote-naming on how we handle application provided user/pass and the silent authentication mechanism.
-
7. Re: EJB remote call does not propagate security principal
jaikiran Jun 20, 2012 2:21 AM (in response to jaikiran)By the way, Dirk, is there a specific reason why you are using remote-naming API approach for invoking on EJBs instead of using the recommended EJB client API approach? To see the difference, you might want to read this https://docs.jboss.org/author/display/AS71/Remote+EJB+invocations+via+JNDI+-+EJB+client+API+or+remote-naming+project
-
8. Re: EJB remote call does not propagate security principal
wdfink Jun 20, 2012 2:26 AM (in response to dweil)Do you notice that teh ApplicationRealm contain
<local default-user="$local" allowed-users="*"/>
The element you've posted is the ManagementRealm
-
9. Re: EJB remote call does not propagate security principal
dweil Jun 21, 2012 1:43 AM (in response to wdfink)Jaikiran,
I'm using the remote-naming API instead of the EJB client API, because our applications have a service locator library in place, which cannot supply the "?stateful" suffix for sfsb lookup names.
I added the two jndi properties SASL_DISALLOWED_MECHANISMS and SASL_POLICY_NOPLAINTEXT without any effect.
Wolf-Dieter,
yes, I noticed the <local> is in both realms. I removed the one from ApplicationRealm.
I hope you enjoyed the Treffpunkt Arminius with my colleague!
-
10. Re: EJB remote call does not propagate security principal
dweil Jun 21, 2012 1:57 AM (in response to dweil)Jaikiran,
I converted the ejb-jar into a war file. Now it works like expected (on JBoss 7.1.1 as well as 7.2.0-ALPHA1)!
-
11. Re: EJB remote call does not propagate security principal
jaikiran Jun 21, 2012 2:00 AM (in response to dweil)The packaging type shouldn't matter in this case. I haven't yet been able to test the application you attached since it requires building that project. Could you please post the output of:
jar -tf your-non-working-ejb-jar.jar
and for the war version:
jar -tf your-working-war.war
-
12. Re: EJB remote call does not propagate security principal
sebastian.koske Jul 19, 2012 4:07 AM (in response to jaikiran)Hi,
I'm having the same problem. We are migrating from AS 5.1.0 to 7.1.2 (build from the tag). We used to use this code in order to set the Principal to get from the SessionContext in our services
SecurityClient client = SecurityClientFactory.getSecurityClient();
client.setVmwideAssociation(true);
client.setSimple(new SimplePrincipal(user), password);
client.login();
Now I followed the instructions from Jaikiran https://docs.jboss.org/author/display/AS71/Remote+EJB+invocations+via+JNDI+-+EJB+client+API+or+remote-naming+project and https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI for EJB Client and Remote Naming. It seems that the creditials put into the Initial Context are only used to authorize the establishment of the remote connection. From the SessionContext I always get "anonymus" as principal.
I can't seem to find a working configuration or example. Can you please give some hints on this issue?
-
13. Re: EJB remote call does not propagate security principal
tmanning Jul 31, 2012 1:22 PM (in response to sebastian.koske)I, too, am experiencing this issue. Getting access to the remote context is fine with the supplied credentials, but the referenced bean doesn't know who the user is because the SessionContext returns "anonymous". Can anyone help?
-
14. Re: EJB remote call does not propagate security principal
wdfink Jul 31, 2012 1:28 PM (in response to tmanning)I'm working current at this area.
The problem is that the user vanished if the ejb.jar (or the bean) does not contain a security-domain.
If you add this the user is available.