[jboss-as7-dev] The principal is not propagated to ejb session context

[Anil Saldhana]

I am not sure why we need an additional valve. For requests #2 till 
infinity,
the SecurityAssociationValve is always called even when the TC has cached
the principal and the realm is not invoked. We can certainly populate 
whatever
we need in terms of security context from the tomcat catalina session.

On 10/18/2011 07:21 AM, Darran Lofthouse wrote:
> 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/4e44ecc0da8aa1b176ba999a352f7dec78b2f234
>
> 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/ea3a9c7823466af2a665ba0febfb2aed051b81b8
>
> 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