[JBoss JIRA] (JBWS-3378) Both JAXWS & JAXRPC handlers have to be executed in EJB interceptor after EJB security interceptors
5:32 a.m.
Both JAXWS & JAXRPC handlers have to be executed in EJB interceptor after EJB security
interceptors
---------------------------------------------------------------------------------------------------
Key: JBWS-3378
URL: https://issues.jboss.org/browse/JBWS-3378
Project: JBoss Web Services
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Reporter: Richard Opalka
6.2.2.4 Security
Handlers associated with a Port component run after authorization has occurred and before
the business logic
method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service
endpoints,
Handlers run after the container has performed the security constraint checks associated
with the servlet
element that defines the Port component. For EJB based service implementations, Handlers
run after method
level authorization has occurred.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:32 a.m.
[
https://issues.jboss.org/browse/JBWS-3378?page=com.atlassian.jira.plugin....
]
Richard Opalka updated JBWS-3378:
---------------------------------
Assignee: Richard Opalka
Fix Version/s: jbossws-native-4.0
jbossws-cxf-4.0
Description:
JSR 109 - Version 1.3 - Chapter 6.2.2.4 Security
Handlers associated with a Port component run after authorization has occurred and before
the business logic
method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service
endpoints,
Handlers run after the container has performed the security constraint checks associated
with the servlet
element that defines the Port component. For EJB based service implementations, Handlers
run after method
level authorization has occurred.
was:
6.2.2.4 Security
Handlers associated with a Port component run after authorization has occurred and before
the business logic
method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service
endpoints,
Handlers run after the container has performed the security constraint checks associated
with the servlet
element that defines the Port component. For EJB based service implementations, Handlers
run after method
level authorization has occurred.
Both JAXWS & JAXRPC handlers have to be executed in EJB
interceptor after EJB security interceptors
---------------------------------------------------------------------------------------------------
Key: JBWS-3378
URL: https://issues.jboss.org/browse/JBWS-3378
Project: JBoss Web Services
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: jbossws-native-4.0, jbossws-cxf-4.0
JSR 109 - Version 1.3 - Chapter 6.2.2.4 Security
Handlers associated with a Port component run after authorization has occurred and before
the business logic
method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service
endpoints,
Handlers run after the container has performed the security constraint checks associated
with the servlet
element that defines the Port component. For EJB based service implementations, Handlers
run after method
level authorization has occurred.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:34 a.m.
[
https://issues.jboss.org/browse/JBWS-3378?page=com.atlassian.jira.plugin....
]
Richard Opalka commented on JBWS-3378:
--------------------------------------
<carlo> ropalka: pong
<ropalka> carlo, I've got EJB related question
<ropalka> carlo, I'm finalizing JAXRPC EJB integration and
<ropalka> carlo, I'm working on JAXRPC server side handlers now
<ropalka> carlo, the requirements for JAXRPC EJB interceptors are:
<ropalka> ---
<ropalka> * According to the ws4ee spec the handler logic must be invoked after the
container
<ropalka> * applied method level security to the invocation.
<ropalka> ---
<ropalka> carlo, where should I hook?
<ropalka> carlo, I see ComponentDescription have classLevelInterceptors and
methodInterceptors
<ropalka> carlo, methodInterceptors seems more appropriate to me
<carlo> you should invoke through the service point view
<ropalka> carlo, this is what I have ATM -
https://github.com/ropalka/jboss-as/blob/jaxrpc-ejb/webservices/server-in...
<ropalka> carlo, and invocations on JAXRPC EJB endpoints are working for me
<ropalka> carlo, newEjbEndpoint() interests U
<carlo> right, that should give you a ComponentView at the end of the day (as in
InvocationHandlerEJB3)
<ropalka> carlo, and this is our EJB invocation abstraction -
https://github.com/ropalka/jboss-as/blob/jaxrpc-ejb/webservices/server-in...
<carlo> right
<carlo> hmm, you need to explain a bit more about handlers
<carlo> the handler logic is the user supplied EJB, not?
<carlo> ropalka: ^
<ropalka> carlo, handler is XML processing handler
<ropalka> carlo, that is configured in webservices.xml
<carlo> ah, a kind of interceptor?
<ropalka> carlo, http://fpaste.org/K9h3/
<ropalka> carlo, yep
<carlo> ropalka: interesting, how did we do it in AS5/6?
<ropalka> carlo, a second ...
<ropalka> carlo, Our old invocation handler - http://fpaste.org/w14B/
<ropalka> carlo, Our old handler interceptor - http://fpaste.org/k7F6/
<carlo> ropalka: and the EJB 3.1 variant?
<ropalka> carlo, it was completely different - http://fpaste.org/AGsk/
<carlo> ropalka: in other words the EJB 3.1 was not compliant?
<carlo> I don't see security before handlers
<ropalka> carlo, neither I
<ropalka> carlo, I need to check JAXWS spec, but I think U'll be right. The
requirement will be the same
* ropalka 's checking JAXWS spec.
<carlo> doesn't RPC/WS specify its own security? the quoted bit doesn't
really say whether it pertains EJB security constraints.
<ropalka> carlo, JSR 109 - Chapter 6.2.2.4 Security -
<ropalka> ---
<ropalka> Handlers associated with a Port component run after authorization has
occurred and before the business logic
<ropalka> method of the Service Implementation bean is dispatched to. For JAX-RPC or
JAX-WS Service endpoints,
<ropalka> Handlers run after the container has performed the security constraint
checks associated with the servlet
<ropalka> element that defines the Port component. For EJB based service
implementations, Handlers run after method
<ropalka> level authorization has occurred.
<ropalka> ---
<ropalka> carlo, version 1.3 of JSR 109 (for clarification)
<carlo> interesting indeed
<ropalka> carlo, IOW U're right our old EJB3 inv. handler is bypassing this
requirement :(
<ropalka> carlo, complete chapter text - http://fpaste.org/ovb9/
<carlo> just downloaded the jsr
<ropalka> :)
<carlo> ropalka: probably the EJB 2.1 construct makes the most sense. Insert an
interceptor at a certain point.
<carlo> which is easier to do in AS7 :-)
<ropalka> carlo, yes, I agree
<ropalka> carlo, :D
<ropalka> carlo, so where/how to hook?
* ropalka 's waiting for suggestions ...
<carlo> EJBViewDescription.getConfigurators().add(new DoTheHandlersConfigurator() {
... } );
* ropalka created JBWS-3378
<jbossbot> jira [JBWS-3378] Both JAXWS & JAXRPC handlers have to be executed in
EJB interceptor after EJB security interceptors [Open (Unresolved) Sub-task, Major,
Richard Opalka] https://issues.jboss.org/browse/JBWS-3378
<carlo> configure(...) { configuration.addViewInterceptor(DoHandlersInterceptors
...) }
<carlo> Then you can do anything in the DoHandlersInterceptor
<carlo> ropalka: %
<ropalka> carlo, thanks Carlo!
<carlo> I hate a German keyboard
<ropalka> :)
Both JAXWS & JAXRPC handlers have to be executed in EJB
interceptor after EJB security interceptors
---------------------------------------------------------------------------------------------------
Key: JBWS-3378
URL: https://issues.jboss.org/browse/JBWS-3378
Project: JBoss Web Services
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: jbossws-native-4.0, jbossws-cxf-4.0
JSR 109 - Version 1.3 - Chapter 6.2.2.4 Security
Handlers associated with a Port component run after authorization has occurred and before
the business logic
method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service
endpoints,
Handlers run after the container has performed the security constraint checks associated
with the servlet
element that defines the Port component. For EJB based service implementations, Handlers
run after method
level authorization has occurred.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:38 a.m.
[
https://issues.jboss.org/browse/JBWS-3378?page=com.atlassian.jira.plugin....
]
Richard Opalka edited comment on JBWS-3378 at 11/3/11 6:37 AM:
---------------------------------------------------------------
<carlo> ropalka: pong
<ropalka> carlo, I've got EJB related question
<ropalka> carlo, I'm finalizing JAXRPC EJB integration and
<ropalka> carlo, I'm working on JAXRPC server side handlers now
<ropalka> carlo, the requirements for JAXRPC EJB interceptors are:
<ropalka> ---
<ropalka> * According to the ws4ee spec the handler logic must be invoked after the
container
<ropalka> * applied method level security to the invocation.
<ropalka> ---
<ropalka> carlo, where should I hook?
<ropalka> carlo, I see ComponentDescription have classLevelInterceptors and
methodInterceptors
<ropalka> carlo, methodInterceptors seems more appropriate to me
<carlo> you should invoke through the service point view
<ropalka> carlo, this is what I have ATM -
https://github.com/ropalka/jboss-as/blob/jaxrpc-ejb/webservices/server-in...
<ropalka> carlo, and invocations on JAXRPC EJB endpoints are working for me
<ropalka> carlo, newEjbEndpoint() interests U
<carlo> right, that should give you a ComponentView at the end of the day (as in
InvocationHandlerEJB3)
<ropalka> carlo, and this is our EJB invocation abstraction -
https://github.com/ropalka/jboss-as/blob/jaxrpc-ejb/webservices/server-in...
<carlo> right
<carlo> hmm, you need to explain a bit more about handlers
<carlo> the handler logic is the user supplied EJB, not?
<carlo> ropalka: ^
<ropalka> carlo, handler is XML processing handler
<ropalka> carlo, that is configured in webservices.xml
<carlo> ah, a kind of interceptor?
<ropalka> carlo, http://fpaste.org/K9h3/
<ropalka> carlo, yep
<carlo> ropalka: interesting, how did we do it in AS5/6?
<ropalka> carlo, a second ...
<ropalka> carlo, Our old invocation handler - http://fpaste.org/w14B/
<ropalka> carlo, Our old handler interceptor - http://fpaste.org/k7F6/
<carlo> ropalka: and the EJB 3.1 variant?
<ropalka> carlo, it was completely different - http://fpaste.org/AGsk/
<carlo> ropalka: in other words the EJB 3.1 was not compliant?
<carlo> I don't see security before handlers
<ropalka> carlo, neither I
<ropalka> carlo, I need to check JAXWS spec, but I think U'll be right. The
requirement will be the same
ropalka 's checking JAXWS spec.
<carlo> doesn't RPC/WS specify its own security? the quoted bit doesn't
really say whether it pertains EJB security constraints.
<ropalka> carlo, JSR 109 - Chapter 6.2.2.4 Security -
<ropalka> ---
<ropalka> Handlers associated with a Port component run after authorization has
occurred and before the business logic
<ropalka> method of the Service Implementation bean is dispatched to. For JAX-RPC or
JAX-WS Service endpoints,
<ropalka> Handlers run after the container has performed the security constraint
checks associated with the servlet
<ropalka> element that defines the Port component. For EJB based service
implementations, Handlers run after method
<ropalka> level authorization has occurred.
<ropalka> ---
<ropalka> carlo, version 1.3 of JSR 109 (for clarification)
<carlo> interesting indeed
<ropalka> carlo, IOW U're right our old EJB3 inv. handler is bypassing this
requirement :(
<ropalka> carlo, complete chapter text - http://fpaste.org/ovb9/
<carlo> just downloaded the jsr
<ropalka> :)
<carlo> ropalka: probably the EJB 2.1 construct makes the most sense. Insert an
interceptor at a certain point.
<carlo> which is easier to do in AS7 :-)
<ropalka> carlo, yes, I agree
<ropalka> carlo, :D
<ropalka> carlo, so where/how to hook?
ropalka 's waiting for suggestions ...
<carlo> EJBViewDescription.getConfigurators().add(new DoTheHandlersConfigurator() {
... } );
ropalka created JBWS-3378
<jbossbot> jira [JBWS-3378] Both JAXWS & JAXRPC handlers have to be executed in
EJB interceptor after EJB security interceptors [Open (Unresolved) Sub-task, Major,
Richard Opalka] https://issues.jboss.org/browse/JBWS-3378
<carlo> configure(...) { configuration.addViewInterceptor(DoHandlersInterceptors
...) }
<carlo> Then you can do anything in the DoHandlersInterceptor
<carlo> ropalka: %
<ropalka> carlo, thanks Carlo!
<carlo> I hate a German keyboard
<ropalka> :)
was (Author: ropalka):
<carlo> ropalka: pong
<ropalka> carlo, I've got EJB related question
<ropalka> carlo, I'm finalizing JAXRPC EJB integration and
<ropalka> carlo, I'm working on JAXRPC server side handlers now
<ropalka> carlo, the requirements for JAXRPC EJB interceptors are:
<ropalka> ---
<ropalka> * According to the ws4ee spec the handler logic must be invoked after the
container
<ropalka> * applied method level security to the invocation.
<ropalka> ---
<ropalka> carlo, where should I hook?
<ropalka> carlo, I see ComponentDescription have classLevelInterceptors and
methodInterceptors
<ropalka> carlo, methodInterceptors seems more appropriate to me
<carlo> you should invoke through the service point view
<ropalka> carlo, this is what I have ATM -
https://github.com/ropalka/jboss-as/blob/jaxrpc-ejb/webservices/server-in...
<ropalka> carlo, and invocations on JAXRPC EJB endpoints are working for me
<ropalka> carlo, newEjbEndpoint() interests U
<carlo> right, that should give you a ComponentView at the end of the day (as in
InvocationHandlerEJB3)
<ropalka> carlo, and this is our EJB invocation abstraction -
https://github.com/ropalka/jboss-as/blob/jaxrpc-ejb/webservices/server-in...
<carlo> right
<carlo> hmm, you need to explain a bit more about handlers
<carlo> the handler logic is the user supplied EJB, not?
<carlo> ropalka: ^
<ropalka> carlo, handler is XML processing handler
<ropalka> carlo, that is configured in webservices.xml
<carlo> ah, a kind of interceptor?
<ropalka> carlo, http://fpaste.org/K9h3/
<ropalka> carlo, yep
<carlo> ropalka: interesting, how did we do it in AS5/6?
<ropalka> carlo, a second ...
<ropalka> carlo, Our old invocation handler - http://fpaste.org/w14B/
<ropalka> carlo, Our old handler interceptor - http://fpaste.org/k7F6/
<carlo> ropalka: and the EJB 3.1 variant?
<ropalka> carlo, it was completely different - http://fpaste.org/AGsk/
<carlo> ropalka: in other words the EJB 3.1 was not compliant?
<carlo> I don't see security before handlers
<ropalka> carlo, neither I
<ropalka> carlo, I need to check JAXWS spec, but I think U'll be right. The
requirement will be the same
* ropalka 's checking JAXWS spec.
<carlo> doesn't RPC/WS specify its own security? the quoted bit doesn't
really say whether it pertains EJB security constraints.
<ropalka> carlo, JSR 109 - Chapter 6.2.2.4 Security -
<ropalka> ---
<ropalka> Handlers associated with a Port component run after authorization has
occurred and before the business logic
<ropalka> method of the Service Implementation bean is dispatched to. For JAX-RPC or
JAX-WS Service endpoints,
<ropalka> Handlers run after the container has performed the security constraint
checks associated with the servlet
<ropalka> element that defines the Port component. For EJB based service
implementations, Handlers run after method
<ropalka> level authorization has occurred.
<ropalka> ---
<ropalka> carlo, version 1.3 of JSR 109 (for clarification)
<carlo> interesting indeed
<ropalka> carlo, IOW U're right our old EJB3 inv. handler is bypassing this
requirement :(
<ropalka> carlo, complete chapter text - http://fpaste.org/ovb9/
<carlo> just downloaded the jsr
<ropalka> :)
<carlo> ropalka: probably the EJB 2.1 construct makes the most sense. Insert an
interceptor at a certain point.
<carlo> which is easier to do in AS7 :-)
<ropalka> carlo, yes, I agree
<ropalka> carlo, :D
<ropalka> carlo, so where/how to hook?
* ropalka 's waiting for suggestions ...
<carlo> EJBViewDescription.getConfigurators().add(new DoTheHandlersConfigurator() {
... } );
* ropalka created JBWS-3378
<jbossbot> jira [JBWS-3378] Both JAXWS & JAXRPC handlers have to be executed in
EJB interceptor after EJB security interceptors [Open (Unresolved) Sub-task, Major,
Richard Opalka] https://issues.jboss.org/browse/JBWS-3378
<carlo> configure(...) { configuration.addViewInterceptor(DoHandlersInterceptors
...) }
<carlo> Then you can do anything in the DoHandlersInterceptor
<carlo> ropalka: %
<ropalka> carlo, thanks Carlo!
<carlo> I hate a German keyboard
<ropalka> :)
Both JAXWS & JAXRPC handlers have to be executed in EJB
interceptor after EJB security interceptors
---------------------------------------------------------------------------------------------------
Key: JBWS-3378
URL: https://issues.jboss.org/browse/JBWS-3378
Project: JBoss Web Services
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: jbossws-native-4.0, jbossws-cxf-4.0
JSR 109 - Version 1.3 - Chapter 6.2.2.4 Security
Handlers associated with a Port component run after authorization has occurred and before
the business logic
method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service
endpoints,
Handlers run after the container has performed the security constraint checks associated
with the servlet
element that defines the Port component. For EJB based service implementations, Handlers
run after method
level authorization has occurred.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:16 a.m.
New subject: [JBoss JIRA] (JBWS-3378) Both JAXWS & JAXRPC handlers have to be executed in EJB component interceptor
[
https://issues.jboss.org/browse/JBWS-3378?page=com.atlassian.jira.plugin....
]
Richard Opalka updated JBWS-3378:
---------------------------------
Summary: Both JAXWS & JAXRPC handlers have to be executed in EJB component
interceptor (was: Both JAXWS & JAXRPC handlers have to be executed in EJB interceptor
after EJB security interceptors)
Description:
JSR 109 - Version 1.3 - Chapter 6.2.2.4 Security
Handlers associated with a Port component run after authorization has occurred and before
the business logic
method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service
endpoints,
Handlers run after the container has performed the security constraint checks associated
with the servlet
element that defines the Port component. For EJB based service implementations, Handlers
run after method
level authorization has occurred.
JSR 109 - Version 1.3 - Chapter 6.2.2.5 Transactions
Handlers run under the transaction context of the component they are associated with.
was:
JSR 109 - Version 1.3 - Chapter 6.2.2.4 Security
Handlers associated with a Port component run after authorization has occurred and before
the business logic
method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service
endpoints,
Handlers run after the container has performed the security constraint checks associated
with the servlet
element that defines the Port component. For EJB based service implementations, Handlers
run after method
level authorization has occurred.
Both JAXWS & JAXRPC handlers have to be executed in EJB component
interceptor
-----------------------------------------------------------------------------
Key: JBWS-3378
URL: https://issues.jboss.org/browse/JBWS-3378
Project: JBoss Web Services
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: jbossws-native-4.0, jbossws-cxf-4.0
JSR 109 - Version 1.3 - Chapter 6.2.2.4 Security
Handlers associated with a Port component run after authorization has occurred and before
the business logic
method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service
endpoints,
Handlers run after the container has performed the security constraint checks associated
with the servlet
element that defines the Port component. For EJB based service implementations, Handlers
run after method
level authorization has occurred.
JSR 109 - Version 1.3 - Chapter 6.2.2.5 Transactions
Handlers run under the transaction context of the component they are associated with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:50 a.m.
New subject: [JBoss JIRA] (JBWS-3378) Both JAXWS & JAXRPC handlers have to be executed in EJB component interceptor
[
https://issues.jboss.org/browse/JBWS-3378?page=com.atlassian.jira.plugin....
]
Alessio Soldano updated JBWS-3378:
----------------------------------
Parent: (was: JBWS-3375)
Issue Type: Task (was: Sub-task)
Both JAXWS & JAXRPC handlers have to be executed in EJB component
interceptor
-----------------------------------------------------------------------------
Key: JBWS-3378
URL: https://issues.jboss.org/browse/JBWS-3378
Project: JBoss Web Services
Issue Type: Task
Security Level: Public(Everyone can see)
Components: jbossws-cxf, jbossws-integration, jbossws-native
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: jbossws-native-4.0, jbossws-cxf-4.0
JSR 109 - Version 1.3 - Chapter 6.2.2.4 Security
Handlers associated with a Port component run after authorization has occurred and before
the business logic
method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service
endpoints,
Handlers run after the container has performed the security constraint checks associated
with the servlet
element that defines the Port component. For EJB based service implementations, Handlers
run after method
level authorization has occurred.
JSR 109 - Version 1.3 - Chapter 6.2.2.5 Transactions
Handlers run under the transaction context of the component they are associated with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:50 a.m.
New subject: [JBoss JIRA] (JBWS-3378) Both JAXWS & JAXRPC handlers have to be executed in EJB component interceptor
[
https://issues.jboss.org/browse/JBWS-3378?page=com.atlassian.jira.plugin....
]
Alessio Soldano updated JBWS-3378:
----------------------------------
Component/s: jbossws-cxf
jbossws-integration
jbossws-native
Both JAXWS & JAXRPC handlers have to be executed in EJB component
interceptor
-----------------------------------------------------------------------------
Key: JBWS-3378
URL: https://issues.jboss.org/browse/JBWS-3378
Project: JBoss Web Services
Issue Type: Task
Security Level: Public(Everyone can see)
Components: jbossws-cxf, jbossws-integration, jbossws-native
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: jbossws-native-4.0, jbossws-cxf-4.0
JSR 109 - Version 1.3 - Chapter 6.2.2.4 Security
Handlers associated with a Port component run after authorization has occurred and before
the business logic
method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service
endpoints,
Handlers run after the container has performed the security constraint checks associated
with the servlet
element that defines the Port component. For EJB based service implementations, Handlers
run after method
level authorization has occurred.
JSR 109 - Version 1.3 - Chapter 6.2.2.5 Transactions
Handlers run under the transaction context of the component they are associated with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:31 a.m.
New subject: [JBoss JIRA] (JBWS-3378) Both JAXWS & JAXRPC handlers have to be executed in EJB component interceptor
[
https://issues.jboss.org/browse/JBWS-3378?page=com.atlassian.jira.plugin....
]
Richard Opalka updated JBWS-3378:
---------------------------------
Assignee: (was: Richard Opalka)
Fix Version/s: jbossws-native-4.1
jbossws-cxf-4.1
(was: jbossws-native-4.0)
(was: jbossws-cxf-4.0)
Both JAXWS & JAXRPC handlers have to be executed in EJB component
interceptor
-----------------------------------------------------------------------------
Key: JBWS-3378
URL: https://issues.jboss.org/browse/JBWS-3378
Project: JBoss Web Services
Issue Type: Task
Security Level: Public(Everyone can see)
Components: jbossws-cxf, jbossws-integration, jbossws-native
Reporter: Richard Opalka
Fix For: jbossws-native-4.1, jbossws-cxf-4.1
JSR 109 - Version 1.3 - Chapter 6.2.2.4 Security
Handlers associated with a Port component run after authorization has occurred and before
the business logic
method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service
endpoints,
Handlers run after the container has performed the security constraint checks associated
with the servlet
element that defines the Port component. For EJB based service implementations, Handlers
run after method
level authorization has occurred.
JSR 109 - Version 1.3 - Chapter 6.2.2.5 Transactions
Handlers run under the transaction context of the component they are associated with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:24 a.m.
New subject: [JBoss JIRA] (JBWS-3378) JAXWS handlers (like JAXRPC handlers are) have to be executed in EJB component interceptor
[
https://issues.jboss.org/browse/JBWS-3378?page=com.atlassian.jira.plugin....
]
Richard Opalka updated JBWS-3378:
---------------------------------
Summary: JAXWS handlers (like JAXRPC handlers are) have to be executed in EJB
component interceptor (was: Both JAXWS & JAXRPC handlers have to be executed in EJB
component interceptor)
Fix Version/s: (was: jbossws-native-4.1)
Component/s: (was: jbossws-native)
JAXWS handlers (like JAXRPC handlers are) have to be executed in EJB
component interceptor
------------------------------------------------------------------------------------------
Key: JBWS-3378
URL: https://issues.jboss.org/browse/JBWS-3378
Project: JBoss Web Services
Issue Type: Task
Security Level: Public(Everyone can see)
Components: jbossws-cxf, jbossws-integration
Reporter: Richard Opalka
Fix For: jbossws-cxf-4.1
JSR 109 - Version 1.3 - Chapter 6.2.2.4 Security
Handlers associated with a Port component run after authorization has occurred and before
the business logic
method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service
endpoints,
Handlers run after the container has performed the security constraint checks associated
with the servlet
element that defines the Port component. For EJB based service implementations, Handlers
run after method
level authorization has occurred.
JSR 109 - Version 1.3 - Chapter 6.2.2.5 Transactions
Handlers run under the transaction context of the component they are associated with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:51 a.m.
New subject: [JBoss JIRA] (JBWS-3378) JAXWS handlers (like JAXRPC handlers are) have to be executed in EJB component interceptor
[
https://issues.jboss.org/browse/JBWS-3378?page=com.atlassian.jira.plugin....
]
Richard Opalka updated JBWS-3378:
---------------------------------
Attachment: (was: JBossWS-IRC-2012-09-06.txt)
JAXWS handlers (like JAXRPC handlers are) have to be executed in EJB
component interceptor
------------------------------------------------------------------------------------------
Key: JBWS-3378
URL: https://issues.jboss.org/browse/JBWS-3378
Project: JBoss Web Services
Issue Type: Task
Security Level: Public(Everyone can see)
Components: jbossws-cxf, jbossws-integration
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: jbossws-cxf-4.1
JSR 109 - Version 1.3 - Chapter 6.2.2.4 Security
Handlers associated with a Port component run after authorization has occurred and before
the business logic
method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service
endpoints,
Handlers run after the container has performed the security constraint checks associated
with the servlet
element that defines the Port component. For EJB based service implementations, Handlers
run after method
level authorization has occurred.
JSR 109 - Version 1.3 - Chapter 6.2.2.5 Transactions
Handlers run under the transaction context of the component they are associated with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:53 a.m.
New subject: [JBoss JIRA] (JBWS-3378) JAXWS handlers (like JAXRPC handlers are) have to be executed in EJB component interceptor
[
https://issues.jboss.org/browse/JBWS-3378?page=com.atlassian.jira.plugin....
]
Richard Opalka commented on JBWS-3378:
--------------------------------------
[09:32:44] <ropalka> asoldano, BTW solving JBWS-3378 & JBWS-3441 is really
challenging task
[09:32:48] <ropalka> asoldano, it's not that easy and I'm still not sure if
doable
[09:33:14] <ropalka> asoldano, there are few clarification questions I still need to
ask myself (analyzing the code)
[09:34:04] <asoldano> ropalka, quite frankly, I'm not going to force you on
working on 3378 :-) IOW, as long as we don't have problems with users/customers we can
probably leave stuff as is
[09:34:31] <ropalka> asoldano, do you want to describe the problem?
[09:35:18] <asoldano> ropalka, I remember something around the relative execution
order of jaxws handlers and ejb3 interceptors...
[09:35:41] <ropalka> asoldano, I'll state the problem to you so you can think
about it too.
[09:35:48] <asoldano> ropalka, ok..
[09:36:12] <ropalka> asoldano, first problem is in CXF everything is executed in
Interceptors chain - WSDL retrieval, SOAP invocations
[09:36:49] <ropalka> asoldano, we need to "merge" this Apache CXF
processing chain with EJB component processing chain
[09:37:09] <ropalka> asoldano, there are two ideas how to fix it I have ATM
[09:37:24] <ropalka> * move all CXF processing chain to EJB interceptor chain
[09:37:48] <ropalka> * move just SOAP handlers processing interceptor to EJB
interceptor chain
[09:38:23] <ropalka> asoldano, first one (moving all) is not doable IMO
[09:39:02] <ropalka> asoldano, because ServiceInvokerInterceptor is part of that
chain and it calls our JBossWS invoker which then calls EJB
[09:39:25] <ropalka> asoldano, without executing most of the Apache CXF interceptor
chain we don't know which method to call (with what arguments)
[09:39:59] <ropalka> asoldano, so it seems only second idea is doable
[09:40:04] <ropalka> asoldano, but it has similar problems
[09:40:16] <asoldano> ropalka, we defintely need to keep on using the apache cxf
interceptors, otherwise each time cxf changes something in them we're broken
[09:41:00] <ropalka> asoldano, I'll comment on it later, let me finish my brain
dump :)
[09:41:01] <ropalka> ---
[09:41:13] <ropalka> asoldano, if we'll just move SOAP handlers processing part
to EJB interceptors chain
[09:41:15] <asoldano> ropalka, sure
[09:41:51] <ropalka> asoldano, we have similar problem because SOAP handlers can
modify the SOAP message significantly.
[09:42:36] <ropalka> asoldano, for example it can change some method parameters that
are later used for invocation
[09:42:44] <ropalka> asoldano, we have some tests like this in our test suite
[09:42:56] <asoldano> ropalka, sure
[09:43:06] <ropalka> asoldano, IOW if we'll move SOAP handlers to the EJB AS7
interceptor chain
[09:43:49] <ropalka> asoldano, then parameters that CXF deserialized from SOAP
message are not holding changes did by SOAP handlers (that will be executed later in EJB
interceptor chain)
[09:43:57] <ropalka> asoldano, it's kinda chicken & egg problem :(
[09:44:59] <ropalka> asoldano, that was the problem description. Let's discuss
it now.
[09:45:35] <ropalka> asoldano, First of all let me say this is the drawback of the
fact Red Hat decided to use thirdparty SOAP stack.
[09:45:59] <ropalka> asoldano, If we used our own, we would have more options how to
solve it - also moving some part of JBossWS to AS 7
[09:46:28] <ropalka> asoldano, but with CXF you need to do some compromises - and
this JIRA is one of them ATM IMO
[09:47:00] <asoldano> ropalka, yeah, I know this
[09:47:09] <ropalka> asoldano, As you said we shouldn't break CXF interceptor
chain
[09:47:13] <asoldano> ropalka, it's an integration problem
[09:47:16] <ropalka> asoldano, and I agree with you.
[09:47:40] <ropalka> asoldano, for example consider situation we'd decided for
Native
[09:47:49] <asoldano> ropalka, I'm re-reading your comments on the jira...
[09:48:00] <ropalka> asoldano, in that case I'd rewrite JBossWS invocation
process in the way
[09:48:19] <ropalka> asoldano, that would be more AS7 friendly
[09:48:35] <ropalka> asoldano, for example Native didn't have concept of
interceptors for everything like CXF has.
[09:48:50] <ropalka> asoldano, Native only had PRE, ENDPOINT & POST
interceptors
[09:49:27] <ropalka> asoldano, but let's forget about Native
[09:51:21] <ropalka> asoldano, IMO this is also the spec shade area problem.
[09:51:43] <asoldano> ropalka, definitely
[09:51:53] <ropalka> asoldano, let's have a look to
WSIntegrationProcessorJAXRPC_EJB.JAXRPCHandlersInterceptor
[09:52:07] <asoldano> ropalka, I'm probably still missing part of the problem...
let me ask few questions:
[09:52:23] <ropalka> asoldano, it tries to deal with the same problem with modified
SOAP message
[09:52:26] <ropalka> asoldano, there's comment
[09:52:27] <ropalka> ---
[09:52:43] <ropalka> // The SOAPContentElements stored in the EndpointInvocation
might have changed after
[09:52:43] <ropalka> // handler processing. Get the updated request payload. This
should be a noop if request
[09:52:43] <ropalka> // handlers did not modify the incomming SOAP message.
[09:52:43] <ropalka> final Object[] reqParams = wsInvocation.getArgs();
[09:52:43] <ropalka> context.setParameters(reqParams);
[09:52:43] <asoldano> ropalka, the problem is that for ejb3 endpoints. the jaxws
handlers needs to be executed after ejb3 authorization...
[09:52:45] <ropalka> final Object resObj = context.proceed();
[09:52:49] <ropalka> ---
[09:52:55] <ropalka> asoldano, ejb3 method authorization
[09:53:01] <ropalka> asoldano, if configured
[09:53:02] <asoldano> ropalka, which is done when we hook into the ejb3 layer in our
invoker
[09:53:21] <ropalka> asoldano, yes, it runs in EJB AS7 interceptor chain - somewhere
in the beginning
[09:53:28] <asoldano> ropalka, but we don't know which method to call before
that and the handlers can influence that?
[09:54:24] <ropalka> asoldano, if we'll move just SOAP handlers processing to
EJB interceptor chain we know which method to call, but parameters may be out of date -
because will be modified in SOAP handlers
[09:54:58] <ropalka> asoldano, see my copy/past of JAXRPC interceptor above
[09:55:06] <asoldano> ropalka, it's like saying that the ejb3 interceptor
processing needs to be split into 2 phases
[09:55:38] <ropalka> asoldano, WDYM - can you elaborate your idea?
[09:57:12] <asoldano> ropalka, just in theory, what I'm saying is that we might
need the to have the ejb3 auth interceptors be executed first, then we go on with the cxf
interceptors (handler ones) and finally get back to the ejb3 interceptors running when the
cxf invoker is called
[09:58:45] <asoldano> ropalka, do you see what I mean?
[09:58:47] <ropalka> ropalka 's compiling the statement ...
[09:59:25] <ropalka> asoldano, I see what you mean and let me describe the problem
[10:00:19] <ropalka> asoldano, first how CXF processing chain looks like
[10:00:20] <ropalka> ---
[10:00:21] <ropalka> receive [PolicyInInterceptor, EndpointAssociationInterceptor,
AttachmentInInterceptor]
[10:00:21] <ropalka> pre-stream [CertConstraintsInterceptor]
[10:00:21] <ropalka> post-stream [StaxInInterceptor]
[10:00:21] <ropalka> read [WSDLGetInterceptor, ReadHeadersInterceptor,
SoapActionInInterceptor, StartBodyInterceptor]
[10:00:23] <ropalka> pre-protocol [EnableDecoupledFaultInterceptor,
MEXInInterceptor, MustUnderstandInterceptor]
[10:00:25] <ropalka> pre-protocol-frontend [SOAPHandlerInterceptor,
LogicalHandlerInInterceptor]
[10:00:27] <ropalka> post-protocol [CheckFaultInterceptor,
JAXBAttachmentSchemaValidationHack]
[10:00:29] <ropalka> unmarshal [URIMappingInterceptor, DocLiteralInInterceptor,
SoapHeaderInterceptor]
[10:00:31] <ropalka> pre-logical [NsCtxSelectorStoreInterceptor,
OneWayProcessorInterceptor]
[10:00:33] <ropalka> post-logical [WrapperClassInInterceptor]
[10:00:35] <ropalka> pre-invoke [SwAInInterceptor, HolderInInterceptor]
[10:00:37] <ropalka> invoke [ServiceInvokerInterceptor]
[10:00:39] <ropalka> post-invoke [OutgoingChainInterceptor]
[10:00:41] <ropalka> ---
[10:00:52] <ropalka> asoldano, the most important phases we need to move to EJB
interceptor chain are
[10:00:54] <ropalka> ---
[10:01:31] <ropalka> pre-protocol, pre-protocol-frontend, post-protocol
[10:01:57] <ropalka> ---
[10:02:07] <ropalka> asoldano, not sure about pre-logical & post-logical but
let's continue
[10:03:14] <ropalka> asoldano, let's say we'll move these phases to EJB
interceptor chain
[10:03:55] <ropalka> asoldano, the invocation goes to our transport, then through
CXF interceptor chain through all the passes except those we moved
[10:04:21] <ropalka> asoldano, at ServiceInvokerInterceptor we'll call JBossWS
invoker which calls EJB invoker which calls EJB interceptor chain
[10:04:32] <ropalka> asoldano, EJB authorization interceptor is called first
[10:05:48] <asoldano> ropalka, ok, and that's not good, because we need that to
run before the jaxws handlers...
[10:05:57] <ropalka> asoldano, then our SOAP handlers (logical and/or soap)
[10:06:03] <ropalka> asoldano, yes (U already see it)
[10:06:30] <asoldano> ropalka, I'm proposing a different approach
[10:06:37] <ropalka> ropalka 's listening ...
[10:07:52] <asoldano> ropalka, basically, to me we'd need to add one (few?) cxf
interceptor in the chain and have that execute the EJB3 auth interceptor only, then we go
on with the usual cxf chain and finally have the rest of the ejb3 interceptor chain
executed when it's the turn of the invoker
[10:08:54] <ropalka> ropalka 's compiling statement ...
[10:09:24] <asoldano> ropalka, instead of moving the cxf interceptors, we need to
split the ejb3 chain and execute it in parts
[10:09:37] <asoldano> ropalka, at the proper times
[10:10:34] <ropalka> asoldano, note that we're executing that EJB interceptor
chain at ServiceInvokerInterceptor which know which EJB, which EJB method & what
params to use
[10:10:55] <ropalka> asoldano, and it relies on some information obtained from some
interceptor that does XML -> Java deserialization
[10:11:20] <asoldano> ropalka, yeah, but I'm assuming we plug this new
interceptor at a point where we have all the required info
[10:11:42] <asoldano> ropalka, and that point should be before the handlers
interceptor are run, otherwise this problem has no solution
[10:12:02] <asoldano> ropalka, regardless of the cxf architecture
[10:12:52] <ropalka> asoldano, U mean to hook EJB3 interceptor to Apache CXF
interceptor chain?
[10:13:13] <ropalka> asoldano, or you mean first part of EJB3 interceptor chain to
hook to Apache CXF interceptor chain somehow?
[10:13:52] <ropalka> asoldano, or (finally) you mean to merge CXF interceptor chain
with EJB3 interceptor chain?
[10:14:25] <asoldano> ropalka, probably the 2nd; basically, afaiu we need to execute
the first part (auth) of the ejb3 interceptor chain earlier in the cxf chain, then finish
the rest of the ejb3 chain at the usual point in the cxf chain (service endpoint invoker)
[10:15:23] <ropalka> asoldano, to clarify the best solution would be 3-rd
[10:15:41] <ropalka> asoldano, IOW to have just one processing chain and order
interceptors according to our needs
[10:16:01] <ropalka> asoldano, the problem is method discovery, method params
discovery are done in CXF interceptor chain
[10:16:33] <ropalka> asoldano, I was thinking about solution to
"automagically" detect EJB, EJB method name and it's params from SOAP
message
[10:17:07] <ropalka> asoldano, but in case I'd be able to do it, WS-Security
would kick our ass again, because if SOAP message is encoded, we cannot automagically
detect :(
[10:18:11] <ropalka> asoldano, IOW what I'm trying to say it's probably JSR
spec problem
[10:18:13] <asoldano> ropalka, we should not reinvent the wheel here, cxf does find
out the name of method, etc at the right point of the chain (where exactly btw?),
that's when we're allowed to call the ejb3 layer
[10:19:09] <asoldano> ropalka, if that's only at the service invoker interceptor
and there's no way for that to happen earlier, there's no solution
[10:19:12] <ropalka> asoldano, i'd guess some interceptor in 'unmarshal'
phase
[10:19:35] <asoldano> ropalka, so after the handlers stuff?
[10:20:17] <ropalka> asoldano, it must be after hanlders stuff, because you can
modify SOAP body - e.g. WS security or modify SOAP params
[10:20:41] <ropalka> asoldano, in order to see everything up 2 date, you have to
execute user handlers - and later see the modified SOAP message
[10:21:03] <asoldano> ropalka, ok, then how can we tell ejb3 layer to check security
for a given method before jaxws handlers if those can change the method that will be run?
[10:21:23] <ropalka> asoldano, this is what I'm claiming - JSR spec problem
[10:21:41] <ropalka> asoldano, this spec omits e.g. WS security encoded SOAP
messages
[10:21:43] <asoldano> ropalka, ok, then is not an integration issue, it's a
non-sense ;-)
[10:22:11] <ropalka> asoldano, I'm sorry but here's my +1
[10:22:45] <ropalka> asoldano, it would be doable if
[10:23:06] <ropalka> asoldano, all the method discoveries would be SOAPAction based
[10:23:19] <ropalka> asoldano, in that case you would know which EJB to call
(request path in URL)
[10:23:29] <ropalka> asoldano, and which method to call (SOAPAction information)
[10:23:53] <ropalka> asoldano, then you would be able to call EJB authorization
interceptors first somehow
[10:24:10] <ropalka> asoldano, but world isn't perfect and SOAPAction is taken
as hint and not used everytime
[10:24:17] <asoldano> ropalka, but we can have invocations with SOAPAction =
""...
[10:24:25] <ropalka> asoldano, and we have
[10:25:16] <asoldano> ropalka, so this is the key point of the problem
[10:26:45] <ropalka> asoldano, yes, because of optional SOAPAction information and
WS-Security may be used in SOAP message that might prevent to automagically detect EJB
method early in the processing
[10:27:09] <ropalka> asoldano, as I said earlier kinda chicken & egg problem :)
[10:27:50] <asoldano> ropalka, ws-security is not part of the problem imho
[10:28:09] <asoldano> ropalka, as you already decrypt message before dealing with
jaxws handlers
[10:28:28] <asoldano> ropalka, but message routing depending on message payload
contents is a problem
[10:28:39] <asoldano> ropalka, as basically a jaxws handler might change routing
[10:28:50] <ropalka> ropalka 's checking spec ...
[10:29:04] <asoldano> ropalka, but I'm still not sure about this yet...
[10:32:28] <ropalka> asoldano, copy/paste from Webservices13 spec.
[10:32:30] <ropalka> ---
[10:32:30] <ropalka> Server side Handlers run after container services
[10:32:31] <ropalka> have run including method level authorization, but before
demarshalling and dispatching the message to the
[10:32:31] <ropalka> endpoint.
[10:32:31] <ropalka> ---
[10:33:01] <ropalka> asoldano, but it doesn't say you cannot change message
routing.
[10:33:29] <ropalka> asoldano, IMO it is allowed to:
[10:33:30] <ropalka> ---
[10:33:43] <ropalka> asoldano, let's say there's no SOAPAction provided in
HTTP header field
[10:33:56] <ropalka> asoldano, and bar() method is encoded in SOAP request
[10:34:21] <ropalka> asoldano, I have "custom" handler that removes bar()
encoded information and adds foo()
[10:34:52] <ropalka> asoldano, then our JAXB deserializer detects foo() to be
executed (although bar() was executed by client)
[10:35:18] <ropalka> asoldano, then my handler translates foo() response back to
bar() response and
[10:35:34] <ropalka> asoldano, client gets bar() response - but didn't see foo()
was executed
[10:35:43] <ropalka> asoldano, this usecase is allowed IMO - didn't find
it's forbidden
[10:36:00] <asoldano> ropalka, it's probably even related to
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-3451
[10:36:00] <ropalka> asoldano, and because message routing is based on SOAP body
discoveries
[10:36:31] <ropalka> asoldano, I'm not authorized to see the issue content
[10:36:38] <ropalka> asoldano, can U send it to me via e-mail?
[10:37:12] <asoldano> ropalka, yeah, it's that CVE about soap action spoofing
that's been solved recently
[10:37:25] <ropalka> asoldano, aha
[10:37:41] <ropalka> asoldano, yes, this is not allowed if SOAPAction is provided
[10:37:50] <ropalka> asoldano, but if it isn't you can route as you wish
[10:37:58] <asoldano> ropalka, iow, to me it still make sense to check the actual
authorization for the method that is *really* being executed
[10:38:16] <ropalka> asoldano, WYM?
[10:38:33] <asoldano> ropalka, that the current situation is at least safe
[10:38:43] <ropalka> asoldano, yes, it is
[10:39:08] <asoldano> ropalka, the problem we have is that according to the jsr,
we're probably running the jaxws handlers in some circumstances when we should not run
them
[10:39:42] <ropalka> asoldano, I see what you mean
[10:39:47] <asoldano> ropalka, ie. when we have an ejb3 endpoints, we have handlers,
there's security on, and the calling user is not allowed to call the method he wants
[10:40:31] <ropalka> asoldano, i see, the intent is not to execute user handlers at
all if security denies its access
[10:40:57] <asoldano> ropalka, so, what we might do is
[10:41:41] <asoldano> ropalka, figure out if there's a way to hook into ejb3 for
knowing if user is allowed according to the info we have when running the jaxws handler
and still leave stuff as is in the service invoker
[10:42:07] <asoldano> ropalka, as the handlers might change the method, etc.
[10:43:44] <ropalka> asoldano, it's a solution proposal or you're just
thinking loud?
[10:44:01] <asoldano> ropalka, thinking loud
[10:44:13] <ropalka> asoldano, ok
[10:44:21] <ropalka> ropalka 's compiling the statement again ...
[10:44:52] <ropalka> asoldano, you mean to introduce CXF interceptor that is able to
detect this somehow?
[10:46:48] <asoldano> ropalka, well, we still need to verify how and where the
method is actually decided in cxf... and introduce a new cxf that does that early and use
the info for calling ejb3 auth checks
[10:47:02] <asoldano> ropalka, if and only if there're jaxws handlers
[10:49:27] <ropalka> asoldano, I'll have a look where method is decided ...
[10:50:25] <ropalka> asoldano, here's EJB3 code -
jboss-as/ejb3/src/main/java/org/jboss/as/ejb3/security/AuthorizationInterceptor.java
[10:50:25] <asoldano> ropalka, this said, is it actually possible to call the auth
part only of the ejb3 chain?
[10:50:41] <ropalka> asoldano, ATM no
[10:51:03] <ropalka> asoldano, wait. It's doable if U'll configure custom
interceptor
[10:51:18] <ropalka> asoldano, that we will insert just after authorization &
transaction interceptor
[10:51:40] <ropalka> asoldano, but transaction interceptor might start transaction
[10:51:47] <ropalka> ropalka 's thinking loud if that might be the problem
[10:52:24] <ropalka> asoldano, this is part of that JIRA
[10:52:24] <ropalka> ---
[10:52:25] <ropalka> JSR 109 - Version 1.3 - Chapter 6.2.2.5 Transactions
[10:52:25] <ropalka> Handlers run under the transaction context of the component
they are associated with.
[10:52:26] <ropalka> ---
[10:53:06] <ropalka> asoldano, thus I'm thinking loud if executing just first
part of EJB interceptor chain (that would include Authorization & Transaction
interceptors)
[10:53:19] <ropalka> asoldano, and then executing it again - but this time fully
isn't a transaction problem?
[10:53:29] <asoldano> ropalka, it is
[10:54:05] <asoldano> ropalka, so we're back at the beginning
[10:54:36] <ropalka> asoldano, yes, until we'll have all the CXF interceptors
part of EJB3 interceptor chain we're still in trouble :(
[10:54:36] <asoldano> ropalka, we start a transaction believe we're executing a
given ejb3 method and after the handlers we figure out we should have run a different one?
;-)
[10:54:51] <asoldano> ropalka, again, it's not a cxf specific issue afaics
[10:55:10] <ropalka> asoldano, not cxf specific, but CXF integration specific
[10:55:19] <ropalka> asoldano, if you would own the code base you can do everything
...
[10:55:35] <asoldano> ropalka, forget about cxf for a second them
[10:55:38] <asoldano> s/them/then
[10:55:54] <asoldano> ropalka, what you do in the case above? you rollback the
transaction and start another one?
[10:56:11] <ropalka> ropalka 's not tx expert
[10:56:22] <ropalka> asoldano, I have no idea. Maybe maestro may help here
[10:57:03] <ropalka> asoldano, if transaction EJB interceptor is ordered after
authorization interceptor
[10:57:27] <ropalka> asoldano, we'd execute only part of the EJB interceptor
chain where authorization interceptor chain is the last element
[10:57:27] <asoldano> ropalka, what I'm saying that this tx issue, as well as
the security issue, is related to the fact we don't have final info on the ejb3 method
to run until the jaxws handlers processing is over
[10:57:44] <ropalka> asoldano, right
[10:58:14] <ropalka> ropalka 's going to debug Apache CXF to identify where
method & params are detected
[10:58:19] <ropalka> asoldano, give me few minutes ...
[10:58:22] <asoldano> ropalka, OK
[10:59:29] <ropalka> ropalka 's staring IDE ...
[10:59:35] <ropalka> s/staring/booting/
[10:59:52] <asoldano> asoldano often stares at the IDE :-P
[11:00:06] <ropalka> asoldano, me daily :)
[11:00:16] <ropalka> LOL
[11:00:20] <asoldano> :)
[11:12:30] <ropalka> asoldano, SOAPHandlerInterceptor
[11:12:52] <ropalka> asoldano, there's method identified
[11:13:09] <ropalka> asoldano, and it's also the same interceptor that is
executing SOAP handlers
[11:15:55] <asoldano> ropalka, ah, really...
[11:16:21] <asoldano> ropalka, so cxf detects the final info on method just before
or just after handlers execution?
[11:16:40] <ropalka> asoldano, before, according to SOAP message
[11:16:54] <ropalka> asoldano, the method discovery code is at
[11:17:22] <ropalka> asoldano,
AbstractJAXWSHandlerInterceptor.setupBindingOperationInfo()
[11:17:32] <ropalka> asoldano, this method is inherited in SOAPHandlerInterceptor
[11:18:36] <ropalka> asoldano, and this is a bug IMO :)
[11:18:57] <ropalka> asoldano, I mean that method discovery is before handlers are
executed - considering there may be routing handler :)
[11:19:13] <asoldano> ropalka, either a bug or the handler is not actually allowed
to change routing
[11:19:28] <asoldano> ropalka, either ways, this would probably be good for us
[11:27:18] <ropalka> asoldano, right
[11:27:36] <ropalka> asoldano, I'd say routing shouldn't be possible.
[11:27:42] <ropalka> ropalka 's checking the spec. again ...
[11:27:56] <asoldano> ropalka, if this is not a bug, there's likely a way (in
theory) for solving this, but that would imply running the ejb3 chain in 2 parts and also
dealing with transaction issues
[11:28:13] <asoldano> ropalka, basically, you just discovered that we're also
running the jaxws handlers out of transactions
[11:28:24] <asoldano> ropalka, while we should run them in the same tx of the ejb3
invocation
[11:28:33] <ropalka> asoldano, we don't need to deal with transaction issues if
TX interceptor is after Authorization interceptor
[11:28:35] <asoldano> ropalka, afaiu
[11:28:45] <ropalka> asoldano, in first round we'd run EJB3 interceptor till
Authorization one
[11:28:49] <ropalka> asoldano, next round we'll run it all
[11:29:01] <asoldano> ropalka, I'm referring to the JSR 109 - Version 1.3 -
Chapter 6.2.2.5 Transactions you quoted above
[11:29:16] <ropalka> asoldano, this applies to SOAP & Logical handlers only
[11:29:27] <ropalka> asoldano, which we plan to move to EJB3 interceptor
[11:29:37] <asoldano> ropalka, how?
[11:30:27] <ropalka> asoldano, I have an idea - it's identical to what we have
in Native JAXRPC
[11:30:38] <ropalka> asoldano, via HandlerDelegate SPI
[11:31:04] <asoldano> ropalka, here is where we most likely have a cxf requirements
preventing that:
[11:31:16] <ropalka> asoldano, sorry HandlerCallback
[11:32:01] <asoldano> ropalka, cxf chain has interceptors which are meant to be
executed *after* the jaxws handler interceptors, so we should not delay the handlers
execution till the invoker
[11:32:30] <asoldano> ropalka, this is really configuring as a discussion topic for
the ws meeting btw
[11:32:44] <asoldano> ropalka, with a whiteboard support, etc
[11:32:45] <ropalka> asoldano, I planned to discuss it there :)
[11:33:07] <ropalka> asoldano, I saw it in the same light on yesterday when diving
in this problem ...
[11:35:08] <ropalka> asoldano, I'm heading to lunch now. TTYL
[11:35:17] <asoldano> ropalka, just a sec
[11:35:20] <ropalka> asoldano, sure
[11:35:35] <asoldano> ropalka, at the end of the day, I still believe we need to
have a way of running the ejb3 interceptor chain in 2 parts
[11:35:49] <ropalka> asoldano, WDYT so?
[11:35:54] <asoldano> ropalka, both for security and tx reasons
[11:36:18] <asoldano> ropalka, we should probably finish gathering info before the
meeting
[11:36:20] <ropalka> asoldano, because IMO cxf interceptor chain & EJB3
interceptor chain should be merged.
[11:36:29] <ropalka> asoldano, I plan to
[11:36:43] <asoldano> ropalka, and discuss this there, possibly also getting in
touch with the ejb3 guys there
[11:36:54] <ropalka> asoldano, that would be great
[11:37:13] <ropalka> asoldano, mainly Stuart & Jaikiran
[11:37:32] <asoldano> ropalka, so this means that
[11:37:38] <ropalka> asoldano, you should let them know to count with WS meeting
[11:37:46] <ropalka> asoldano, so they'll book hotel accordingly
[11:37:56] <asoldano> ropalka, this jira is going out of 4.1 schedule
JAXWS handlers (like JAXRPC handlers are) have to be executed in EJB
component interceptor
------------------------------------------------------------------------------------------
Key: JBWS-3378
URL: https://issues.jboss.org/browse/JBWS-3378
Project: JBoss Web Services
Issue Type: Task
Security Level: Public(Everyone can see)
Components: jbossws-cxf, jbossws-integration
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: jbossws-cxf-4.1
JSR 109 - Version 1.3 - Chapter 6.2.2.4 Security
Handlers associated with a Port component run after authorization has occurred and before
the business logic
method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service
endpoints,
Handlers run after the container has performed the security constraint checks associated
with the servlet
element that defines the Port component. For EJB based service implementations, Handlers
run after method
level authorization has occurred.
JSR 109 - Version 1.3 - Chapter 6.2.2.5 Transactions
Handlers run under the transaction context of the component they are associated with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:13 a.m.
New subject: [JBoss JIRA] (JBWS-3378) JAXWS handlers (like JAXRPC handlers are) have to be executed in EJB component interceptor
[
https://issues.jboss.org/browse/JBWS-3378?page=com.atlassian.jira.plugin....
]
Alessio Soldano updated JBWS-3378:
----------------------------------
Fix Version/s: (was: jbossws-cxf-4.1)
JAXWS handlers (like JAXRPC handlers are) have to be executed in EJB
component interceptor
------------------------------------------------------------------------------------------
Key: JBWS-3378
URL: https://issues.jboss.org/browse/JBWS-3378
Project: JBoss Web Services
Issue Type: Task
Security Level: Public(Everyone can see)
Components: jbossws-cxf, jbossws-integration
Reporter: Richard Opalka
Assignee: Richard Opalka
JSR 109 - Version 1.3 - Chapter 6.2.2.4 Security
Handlers associated with a Port component run after authorization has occurred and before
the business logic
method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service
endpoints,
Handlers run after the container has performed the security constraint checks associated
with the servlet
element that defines the Port component. For EJB based service implementations, Handlers
run after method
level authorization has occurred.
JSR 109 - Version 1.3 - Chapter 6.2.2.5 Transactions
Handlers run under the transaction context of the component they are associated with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
4466
days inactive
4774
days old
jbossws-issues@lists.jboss.org
11 comments
7 participants
participants (7)
-
Alessio Soldano (JIRA) -
Alessio Soldano (Updated) (JIRA)
-
Richard Opalka (Commented) (JIRA)
-
Richard Opalka (Created) (JIRA)
-
Richard Opalka (Issue Comment Edited) (JIRA)
-
Richard Opalka (JIRA)
-
Richard Opalka (Updated) (JIRA)