7:21 a.m.
No that is not correct, you can not rely on the behaviour of the realm
as that is only called when authentication is actually required, if the
user has already been authenticated the realm is not called.
This latest issue seems to be going back to the same area as we already
solved for: -
https://issues.jboss.org/browse/AS7-989
My proposed change at the time was to use a pair of valves so that the
SecurityContext could be associated with the Thread before the
authentication steps, this valve would also be responsible for clearing
it - a second valve would then be responsible for associated the
pre-authenticated principal with that context: -
https://github.com/darranl/jboss-as/commits/AS7-989
In the end an approach to combine the two valves into one was chosen and
the valve added at the very end: -
https://github.com/darranl/jboss-as/commit/4e44ecc0da8aa1b176ba999a352f7d...
However as the ExtendedFormAuthenticator has been introduced it appears
that the need for the early SecurityContext association has been
identified and that the valve has been pulled back earlier in the calls: -
https://github.com/darranl/jboss-as/commit/ea3a9c7823466af2a665ba0febfb2a...
So now we are back at the point where we are missing a valve after the
authenticator for the actual association of the authenticated user.
Regards,
Darran Lofthouse.
On 10/18/2011 12:42 PM, Anil Saldhana wrote:
The SecurityAssociationValve (which should in fact be named
SecurityContextValve) sets up the SecurityContext for the web container
authentication. The web container auth starts with Authenticator which
will invoke the realm (JBossWebRealm). The realm will perform the
authentication and create a subject. Right then, the subject needs to
be pushed onto the Security Context. Now when the call goes to any
other EE component such as EJB3, that integration needs to pick the
SecurityContext details.
I support the creation of a JIRA issue to track this example deployment.
Thanks JP. :)
On 10/18/2011 06:18 AM, Jaikiran Pai wrote:
> This indeed appears to be a bug. I also looked at our AS7 testsuite and
> all of those tests do programatic login within the servlet or the tests
> before invoking the bean. Dieter, on the other hand uses container
> managed login (FORM based) and is running into this issue.
>
> I looked into the code and IMO the
> org.jboss.as.web.security.SecurityContextAssociationValve (which is
> setting up the principal) is added at the wrong place. This valve is the
> first one to be executed even before the FormBasedAuthenticatorValve
> kicks in. As a result, the SecurityContextAssociationValve doesn't have
> the right principal to associate with the request.
>
> Dieter, could you please create a JIRA for this (if you haven't yet)
> here https://issues.jboss.org/browse/AS7
>
> -Jaikiran
>
> On Tuesday 18 October 2011 03:18 PM, Jaikiran Pai wrote:
>> Thanks. I'm having a look.
>>
>> -Jaikiran
>> On Tuesday 18 October 2011 03:08 AM, Dieter Tengelmann wrote:
>>> Hi, Anil,
>>>
>>> I've attached ear file and sources at the forum thread:
>>> http://community.jboss.org/thread/173494
>>>
>>> Best regards,
>>> Dieter
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev