6:21 p.m.
Hi,
A while back I reported https://issues.jboss.org/browse/SECURITY-746 and
https://issues.jboss.org/browse/SECURITY-876
746 has been open for a long time, while 876 is relatively new.
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.
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.
Kind regards,
Arjan Tijms
2:55 p.m.
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.
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. The Elytron project will tackle the security context
propagation issues that we have today, so anything we code for WF9 in
that sense will be just a temporary band aid.
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. 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.
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.
It is not the best solution but might be ok as a workaround until
Elytron gets properly integrated.
On 05/05/2015 08:21 PM, arjan tijms wrote:
Hi,
A while back I reported https://issues.jboss.org/browse/SECURITY-746
and https://issues.jboss.org/browse/SECURITY-876
746 has been open for a long time, while 876 is relatively new.
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.
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.
Kind regards,
Arjan Tijms
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3:59 p.m.
Hi,
On Thu, May 7, 2015 at 9:55 PM, Stefan Guilhen <sguilhen(a)redhat.com> wrote:
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.
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:
https://issues.jboss.org/browse/WFLY-4602 I think it finally has found the
right place ;)
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.
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.
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.
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".
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).
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.
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.
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.
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.
It is not the best solution but might be ok as a workaround until Elytron
gets properly integrated.
Well, it sounds like a very obvious and straightforward solution.
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).
Kind regards,
Arjan Tijms
On 05/05/2015 08:21 PM, arjan tijms wrote:
Hi,
A while back I reported https://issues.jboss.org/browse/SECURITY-746 and
https://issues.jboss.org/browse/SECURITY-876
746 has been open for a long time, while 876 is relatively new.
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.
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.
Kind regards,
Arjan Tijms
_______________________________________________
wildfly-dev mailing
listwildfly-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3540
days inactive
3542
days old
2 comments
2 participants
participants (2)
-
arjan tijms -
Stefan Guilhen