<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 7, 2015 at 9:55 PM, Stefan Guilhen <span dir="ltr"><<a href="mailto:sguilhen@redhat.com" target="_blank">sguilhen@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>I'll move these issues over to WildFly
as they have nothing to do with PicketBox. I'm currently looking
into 876 (logout not clearing the context) and it should be fixed
for WF9.<br></div></div></blockquote><div><br></div><div>876 indeed seemed wrong in PicketBox, I'm not sure what I was thinking back then. As I think the problem wasn't even JASPIC specific, I filed a new issue in Undertow which Stuart then moved to WildFly, where it's now at: <a href="https://issues.jboss.org/browse/WFLY-4602">https://issues.jboss.org/browse/WFLY-4602</a> I think it finally has found the right place ;)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>Regarding SECURITY-746, historically the EJB container has always
setup a new security context when a call is made to a protected
EJB. There is no mechanism in place to skip any authentication and
just trust the incoming context.</div></div></blockquote><div><br></div><div>Yes I know, although it's maybe extra confusing that when the EJB is not protected (doesn't use the implicit interceptor for @RolesAllowed), but does use the security machinery manually (via the ejb context), then the authenticated identity that was established in the web layer is available to the EJB bean.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>Its also worth saying that this issue affects mainly apps that use
JASPIC for authentication - most of the time applications use
regular JAAS based security domains so usually the same domain and
login modules are involved in both Web and EJB authentication.</div></div></blockquote><div><br></div><div>Indeed, in those cases the web layer has an authentication mechanism defined (e.g. Servlet's FORM) that always delegates to what we call an "identity store" in the security EG (which is roughly a JAAS login module). EJB doesn't have the authentication mechanism concept, and only uses the "identity store". </div><div><br></div><div>Effectively the problem is still there though, as you have to make sure as a developer that the web and ejb layers use the same domain/module, plus you don't really want to re-authenticate for every call to every secured EJB all the time. JBoss works around this problem by using an authentication cache. So effectively you could perhaps say that with the proprietary JAAS based domains the identity does propagate, via the cache. I think it rarely happens that the JAAS module is indeed called following a call from a Servlet to an EJB as it almost always hits the cache (before JASPIC I used the JBoss specific JAAS modules for a long time).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
When using JASPIC, the EJB app might need a different domain
configuration to handle its authentication, which is an annoyance.
Anil tried getting around that in the past by setting the so
called "login-module-stack" in the JASPIC configuration, so that
both Web and EJB layers would end up doing the regular JAAS based
login and thus you wouldn't need a different domain configuration.
However, a JASPIC module is not required to go through JAAS, so I
can see why that can be a problem.<br></div></div></blockquote><div><br></div><div>This solution that Anil had back then is still something that's worth investigating today. A JASPIC module is indeed not required to delegate to an "identity store", but it would be great if there was a standard mechanism to configure that it should do that and a means for the container to see that this configuration is in place. There's the JASPIC bridge profile that somewhat says something about this, but I'm not sure that this would work here.</div><div><br></div><div>Another thing to consider is that in modern Java EE programming EJB beans are often just local and very simple beans that are even put directly in the war. Mentally there is no "web layer" or "ejb layer" in the sense as there once was when remote EJBs and separate EJB modules where more the norm. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>That being said, one possible solution would be to reuse the
incoming context if it already contains an authenticated subject
and if the security domain of the incoming context matches the one
configured in the EJB app. This would probably need a flag like
"trust-incoming-security-context" in the EJB subsystem because it
will change how the server handles authentication in EJB container
and how existing apps are protected. The default value would be
false to preserve current behavior but one could change it to true
in order to reuse the context that was established in the Web
layer. Of course, if the EJB app defines a different security
domain then we create a new context and enforce authentication
against this domain instead of trusting an incoming security
context.<br>
<br>
It is not the best solution but might be ok as a workaround until
Elytron gets properly integrated.</div></div></blockquote><div><br></div><div>Well, it sounds like a very obvious and straightforward solution. </div><div><br></div><div>Just wondering, but did you ever check how some other other servers do this? As far as I know almost all of them automatically propagate the context from a Servlet to an EJB bean (at least GlassFish, WebLogic and Geronimo do this for sure).</div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div><div><div class="h5"><br>
<br>
On 05/05/2015 08:21 PM, arjan tijms wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div class="h5">
<div dir="ltr">Hi,
<div><br>
</div>
<div>A while back I reported <a href="https://issues.jboss.org/browse/SECURITY-746" target="_blank">https://issues.jboss.org/browse/SECURITY-746</a>
and <a href="https://issues.jboss.org/browse/SECURITY-876" target="_blank">https://issues.jboss.org/browse/SECURITY-876</a></div>
<div><br>
</div>
<div>746 has been open for a long time, while 876 is relatively
new.</div>
<div><br>
</div>
<div>Both concern propagation of the authenticated identity from
Servlet to EJB, something which unfortunately has seen bugs in
some form of the other for several years now.</div>
<div><br>
</div>
<div>Would really be great if this can be fixed. I provided a
possible workaround for 876, and a reproducer test for both
issues. If needed I can help more.</div>
<div><br>
</div>
<div>Kind regards,</div>
<div>Arjan Tijms</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
wildfly-dev mailing list
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br></blockquote></div><br></div></div>