Announcement Announcement Module
No announcement yet.
@Endpoint & @PayloadRoot in conjunction with global-method-security @Secured Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • @Endpoint & @PayloadRoot in conjunction with global-method-security @Secured


    I have successfully built up a Spring-WS project using:
    * JAXB2 OXMs and a GenericMarshallingMethodEndpointAdapter for marshalling/unmarshalling,
    * Saaj soap message factory,
    * a PayloadRootAnnotationMethodEndpointMapping,
    * Interfaces and implementations for our endpoints (@Endpoint) with @PayloadRoot marking endpoint methods as handlers for incoming messages, and
    * Spring security for container-based authentication (utilising the a PreAuthenticatedAuthenticationProvider and authentication-manager) - and coarse-grained authorisation (ie: can the user access the context uri, or not...).

    This all works beautifully. If only that was the end of it!

    I'm also looking to utilise global-method-security to authorise execution of endpoint methods, and if not authorised, throw the appropriate exceptions up back through the stack to be translated into soap faults.

    My question is: is it possible to use @PayloadRoot in conjunction with @Secured? Has this been tested?

    It seems that any time I try to do this (ie add @Secured to an Endpoint method), I get:
    java.lang.IllegalArgumentException: [email protected]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Native
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(De
    at java.lang.reflect.Method.invoke(
    at int.invoke(
    at shallingMethodEndpointAdapter.invokeInternal(Marsh
    at tractMethodEndpointAdapter.invoke(AbstractMethodEn
    at spatch(
    at ceive(
    at eMessageReceiverObjectSupport.handleConnection(Web
    at ssageReceiverHandlerAdapter.handle(WebServiceMessa
    at tcherServlet.doService(MessageDispatcherServlet.ja va:230)
    at org.springframework.web.servlet.FrameworkServlet.p rocessRequest(
    at org.springframework.web.servlet.FrameworkServlet.d oPost(
    at javax.servlet.http.HttpServlet.service(HttpServlet .java:727)
    at javax.servlet.http.HttpServlet.service(HttpServlet .java:820)
    at weblogic.servlet.internal.StubSecurityHelper$Servl
    at weblogic.servlet.internal.StubSecurityHelper.invok eServlet(
    at weblogic.servlet.internal.ServletStubImpl.execute(
    at weblogic.servlet.internal.TailFilter.doFilter(Tail
    at weblogic.servlet.internal.FilterChainImpl.doFilter (
    at $VirtualFilterChain.doFilter( :378)
    at ecurityInterceptor.invoke(FilterSecurityIntercepto
    at ecurityInterceptor.doFilter(FilterSecurityIntercep
    at $VirtualFilterChain.doFilter( :390)
    at onFilter.doFilterHttp(ExceptionTranslationFilter.j ava:101)
    at er.doFilter(
    at $VirtualFilterChain.doFilter( :390)
    at eAuthenticatedProcessingFilter.doFilterHttp(Abstra
    at er.doFilter(
    at $VirtualFilterChain.doFilter( :390)
    at ntextIntegrationFilter.doFilterHttp(HttpSessionCon
    at er.doFilter(
    at $VirtualFilterChain.doFilter( :390)
    at .doFilter(
    at org.springframework.web.filter.DelegatingFilterPro xy.invokeDelegate(
    at org.springframework.web.filter.DelegatingFilterPro xy.doFilter(
    at weblogic.servlet.internal.FilterChainImpl.doFilter (
    at weblogic.servlet.internal.WebAppServletContext$Ser :3393)
    at t.doAs(
    at known Source)
    at weblogic.servlet.internal.WebAppServletContext.sec uredExecute(
    at weblogic.servlet.internal.WebAppServletContext.exe cute(
    at java:200)
    at :172)
    I've noticed that providing a pointcut (and removing all @Secured annotations) incurs the same IllegalArgumentException problem:

    <sec:global-method-security secured-annotations="enabled" >
            <!-- Add all cross-cutting security constraints here -->
            <sec:protect-pointcut expression="execution(**(..))" access="ROLE_APP_FN_READ"/>
    I've also noticed this when the bean factory for my XmlWebApplicationContext initialises, a number of beans are not eligible for getting processed by all BeanPostProcessors. Is this important (I think it may be), and how can I fix this?
    78333 [[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  - Bean factory for application context [[email protected]2c8072b]:[email protected]
    88755 [[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  - Bean '(inner bean)' is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
    89105 [[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  - Bean '_delegatingMethodDefinitionSource' is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
    90209 [[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  - Bean '_methodDefinitionSourceAdvisor' is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
    Anyone have any ideas or suggestions?


    Deployment specs:
    AppServer: Weblogic (also tried on JBoss)
    JDK: JRockit and SUN JDK 1.5
    Spring Security 2.0.4
    Spring-WS 1.5.7
    Spring-OXM 1.5.7
    AspectJ 1.6.5
    Xerces Impl 2.9.1
    JAXB-Api 2.0
    wsdl4j 1.6.2

  • #2
    Hi again,

    I've tried every combination in the book, but could not get this going.

    Webservices work fine, but as soon as I apply @Secured or even global-method-security pointcuts against them: IllegalArgumentException. I think there may be some out of the box autoproxying problems that stop this from working properly.

    Looks like I'm going to need to apply authorisation constraints at the business layer (instead of at the payloadroot/ws endpoint).

    If anyone has any suggestions, I'd be very excited to hear from you.



    • #3
      I've encountered similar issue. Just asked for improvement on this Spring-WS JIRA issue.


      • #4
        Thanks for raising this jira improvement Stevo.

        Great to hear I'm not the only one facing this problem.