The principal is not propagated to ejb session context

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

The principal is not propagated to ejb session context

Dieter Tengelmann
Major security bug or configuration problem?
The principal is not propagated to ejb session context. Is this a known bug?
Or is anything wrong with my configuration? I've tested it with the nightly build of 2010-10-08

jboss-web.xml:
--------
    <security-domain flushOnSessionInvalidation="true">myDomain</security-domain>
    <valve>
        <class-name>org.apache.catalina.authenticator.FormAuthenticator</class-name>
    </valve>
---------

security-configuration in standalone.xml
----------
                <security-domain name="myDomain">
                    <authentication>
                        <login-module code="org.jboss.security.auth.spiDatabaseServerLoginModule" flag="required">
                            <module-option name="debug" value="true" />
                            <module-option name="dsJndiName" value="java:/mydb" />
                            <module-option name="principalsQuery" value="SELECT passwd etc" />
                            <module-option name="rolesQuery" value="SELECT role etc." />
                            <module-option name="unauthenticatedIdentity" value="nobody" />                      
                        </login-module>
                    </authentication>
                </security-domain>

Ejb session bean
-------------
@Stateless(name="MyService")
@TransactionManagement(TransactionManagementType.CONTAINER)
@org.jboss.ejb3.annotation.SecurityDomain(value = "myDomain")
public class MyServiceBean {

 
@Resource SessionContext ctx;

---------------------------

jboss.xml
----------------------
<security-domain>myDomain</security-domain>
----------------------

web.xml
----------------------------
<login-config>
      <auth-method>FORM</auth-method>
      <form-login-config>
         <form-login-page>login.jsp</form-login-page>
         <form-error-page>login-error.jsp</form-error-page>
      </form-login-config>
   </login-config>
----------------------------


With this configuration ctx.getCallerPrincipal() delivers "anonymous" principal, and not the successful logged in one

If I remove security-domain from ejb session bean, I get a
javax.ejb.EJBException: java.lang.IllegalStateException: No principal available

Is there a workaraound, where exactly is the principal propagated to ejb. Can I use a customized class somewhere?


I've posted already in the forum, without success: http://community.jboss.org/thread/173494

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: The principal is not propagated to ejb session context

Anil Saldhana
Dieter,
  we have to test this scenario. There may be an issue with the ejbContext.getCallerPrincipal() code.  But I would not term this issue as a *major* security issue.  It would be major if you got a principal when you are not supposed to.

Also I am unsure how your code can work because you need to prefix the form-login-page with "/".   AS7 throws error if the jsp is not starting with a "/"

------------------------------
<login-config>
      <auth-method>FORM</auth-method>
      <form-login-config>
         <form-login-page>/login.jsp</form-login-page>
         <form-error-page>/login-error.jsp</form-error-page>
      </form-login-config>
   </login-config>
-----------------------------

Since you are using the standard FORM authentication, you do not need the valve setting in jboss-web.xml.  That is used only when you write your own custom authenticator.
http://community.jboss.org/wiki/JBossAS7SecurityDomainModel

Regards,
Anil

On 10/14/2011 12:54 PM, Dieter Tengelmann wrote:
Major security bug or configuration problem?
The principal is not propagated to ejb session context. Is this a known bug?
Or is anything wrong with my configuration? I've tested it with the nightly build of 2010-10-08

jboss-web.xml:
--------
    <security-domain flushOnSessionInvalidation="true">myDomain</security-domain>
    <valve>
        <class-name>org.apache.catalina.authenticator.FormAuthenticator</class-name>
    </valve>
---------

security-configuration in standalone.xml
----------
                <security-domain name="myDomain">
                    <authentication>
                        <login-module code="org.jboss.security.auth.spiDatabaseServerLoginModule" flag="required">
                            <module-option name="debug" value="true" />
                            <module-option name="dsJndiName" value="java:/mydb" />
                            <module-option name="principalsQuery" value="SELECT passwd etc" />
                            <module-option name="rolesQuery" value="SELECT role etc." />
                            <module-option name="unauthenticatedIdentity" value="nobody" />                      
                        </login-module>
                    </authentication>
                </security-domain>

Ejb session bean
-------------
@Stateless(name="MyService")
@TransactionManagement(TransactionManagementType.CONTAINER)
@org.jboss.ejb3.annotation.SecurityDomain(value = "myDomain")
public class MyServiceBean {

 
@Resource SessionContext ctx;

---------------------------

jboss.xml
----------------------
<security-domain>myDomain</security-domain>
----------------------

web.xml
----------------------------
<login-config>
      <auth-method>FORM</auth-method>
      <form-login-config>
         <form-login-page>login.jsp</form-login-page>
         <form-error-page>login-error.jsp</form-error-page>
      </form-login-config>
   </login-config>
----------------------------


With this configuration ctx.getCallerPrincipal() delivers "anonymous" principal, and not the successful logged in one

If I remove security-domain from ejb session bean, I get a
javax.ejb.EJBException: java.lang.IllegalStateException: No principal available

Is there a workaraound, where exactly is the principal propagated to ejb. Can I use a customized class somewhere?


I've posted already in the forum, without success: http://community.jboss.org/thread/173494
 
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: The principal is not propagated to ejb session context

Anil Saldhana
Hi Dieter,
  as mentioned in thread http://community.jboss.org/thread/173494,  I see that Carlo/Darran have a test case in our testsuite to test this scenario.

Have a look at the provided links.

Regards,
Anil

On 10/14/2011 01:43 PM, Anil Saldhana wrote:
Dieter,
  we have to test this scenario. There may be an issue with the ejbContext.getCallerPrincipal() code.  But I would not term this issue as a *major* security issue.  It would be major if you got a principal when you are not supposed to.

Also I am unsure how your code can work because you need to prefix the form-login-page with "/".   AS7 throws error if the jsp is not starting with a "/"

------------------------------
<login-config>
      <auth-method>FORM</auth-method>
      <form-login-config>
         <form-login-page>/login.jsp</form-login-page>
         <form-error-page>/login-error.jsp</form-error-page>
      </form-login-config>
   </login-config>
-----------------------------

Since you are using the standard FORM authentication, you do not need the valve setting in jboss-web.xml.  That is used only when you write your own custom authenticator.
http://community.jboss.org/wiki/JBossAS7SecurityDomainModel

Regards,
Anil

On 10/14/2011 12:54 PM, Dieter Tengelmann wrote:
Major security bug or configuration problem?
The principal is not propagated to ejb session context. Is this a known bug?
Or is anything wrong with my configuration? I've tested it with the nightly build of 2010-10-08

jboss-web.xml:
--------
    <security-domain flushOnSessionInvalidation="true">myDomain</security-domain>
    <valve>
        <class-name>org.apache.catalina.authenticator.FormAuthenticator</class-name>
    </valve>
---------

security-configuration in standalone.xml
----------
                <security-domain name="myDomain">
                    <authentication>
                        <login-module code="org.jboss.security.auth.spiDatabaseServerLoginModule" flag="required">
                            <module-option name="debug" value="true" />
                            <module-option name="dsJndiName" value="java:/mydb" />
                            <module-option name="principalsQuery" value="SELECT passwd etc" />
                            <module-option name="rolesQuery" value="SELECT role etc." />
                            <module-option name="unauthenticatedIdentity" value="nobody" />                      
                        </login-module>
                    </authentication>
                </security-domain>

Ejb session bean
-------------
@Stateless(name="MyService")
@TransactionManagement(TransactionManagementType.CONTAINER)
@org.jboss.ejb3.annotation.SecurityDomain(value = "myDomain")
public class MyServiceBean {

 
@Resource SessionContext ctx;

---------------------------

jboss.xml
----------------------
<security-domain>myDomain</security-domain>
----------------------

web.xml
----------------------------
<login-config>
      <auth-method>FORM</auth-method>
      <form-login-config>
         <form-login-page>login.jsp</form-login-page>
         <form-error-page>login-error.jsp</form-error-page>
      </form-login-config>
   </login-config>
----------------------------


With this configuration ctx.getCallerPrincipal() delivers "anonymous" principal, and not the successful logged in one

If I remove security-domain from ejb session bean, I get a
javax.ejb.EJBException: java.lang.IllegalStateException: No principal available

Is there a workaraound, where exactly is the principal propagated to ejb. Can I use a customized class somewhere?


I've posted already in the forum, without success: http://community.jboss.org/thread/173494
 
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: The principal is not propagated to ejb session context

Dieter Tengelmann
In reply to this post by Dieter Tengelmann
Thank you Anil for your informations.
In the same thread I posted an easy example application, that demonstrates the problem...
The missing propagation is related to the login-request itself...
It's still serious for me, because the application I want to migrate, is invalidating the http session, if the ejb context gives me an anonymous caller...
http://community.jboss.org/thread/173494
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: The principal is not propagated to ejb session context

Anil Saldhana
Dieter,
   would you be able to email me separately, the simple ear you are
testing (providing source code for the example will help)?

Regards,
Anil

On 10/15/2011 03:56 AM, Dieter Tengelmann wrote:
> Thank you Anil for your informations.
> In the same thread I posted an easy example application, that
> demonstrates the problem...
> The missing propagation is related to the login-request itself...
> It's still serious for me, because the application I want to migrate,
> is invalidating the http session, if the ejb context gives me an
> anonymous caller...
> http://community.jboss.org/thread/173494
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: The principal is not propagated to ejb session context

Dieter Tengelmann
In reply to this post by Dieter Tengelmann
Hi, Anil,

I've attached ear file and sources at the forum thread:

Best regards,
Dieter

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: The principal is not propagated to ejb session context

Jaikiran Pai
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: The principal is not propagated to ejb session context

Jaikiran Pai
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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: The principal is not propagated to ejb session context

Anil Saldhana
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: The principal is not propagated to ejb session context

Darran Lofthouse
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
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: The principal is not propagated to ejb session context

Marcus Moyses
I don't think we need a second valve also. I have a pending pull request
so I'll add a change there to get the principal from the internal
session and associate it with the SecurityContext.

On 10/18/2011 11:32 AM, Anil Saldhana wrote:

> 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
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

--
Marcus Moyses
Senior JBoss Core Developer
JBoss by Red Hat

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: The principal is not propagated to ejb session context

Marcus Moyses
Here is the commit:
https://github.com/mmoyses/jboss-as/commit/ba3c43f8dfc9c201098392c5ebf90474e49aa5a8
if you want to test it.

On 10/18/2011 11:46 AM, Marcus Moyses wrote:

> I don't think we need a second valve also. I have a pending pull request
> so I'll add a change there to get the principal from the internal
> session and associate it with the SecurityContext.
>
> On 10/18/2011 11:32 AM, Anil Saldhana wrote:
>> 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
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

--
Marcus Moyses
Senior JBoss Core Developer
JBoss by Red Hat

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: The principal is not propagated to ejb session context

Dieter Tengelmann
In reply to this post by Dieter Tengelmann
Hi,

I've create the Jira issue: https://issues.jboss.org/browse/AS7-2146

Thank you for your help,
Dieter

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev