Forum Discussion

Mariateresa's avatar
Mariateresa
New Contributor
16 years ago

problems with soapUI testing webservice on weblogic when using @RolesAllowed

I have problems in accessing a method on a webservice on weblogic, if a @RolesAllowed annotation is defined on the method.
If I move the roles restriction to the class level, rather than the method level, than everything works fine.
Does anybody know what I need to do to keep my roles restriction at the method level and make soapUI work?
Thanks, Mariateresa

7 Replies

  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    SmartBear Alumni (Retired)
    Hi,

    hmm.. can you attach the WSDL's generated by WebLogic for your service with and without this option set?

    regards,

    /Ole
    eviware.com
  • There is no difference in the two WSDLs.

    When the roles annotation is defined at method level I get the following error, but when the annotation is at class level the call works fine:


     

     
         
            soapenv:Client.Authentication
            Access Denied to operation executePARPRequest
           
                weblogic.wsee.util.AccessException: Access Denied to operation executePARPRequest
    at weblogic.wsee.security.AuthorizationHandler.handleRequest(AuthorizationHandler.java:62)
    at weblogic.wsee.handler.HandlerIterator.handleRequest(HandlerIterator.java:127)
    at weblogic.wsee.ws.dispatch.server.ServerDispatcher.dispatch(ServerDispatcher.java:85)
    ...

           

         

     



    Thanks, Mariateresa
  • JimL's avatar
    JimL
    Contributor
    Hi,

    When you say that there is no difference between the two WSDLs, where are you looking at/getting the WSDLs from?

    With WebLogic, if you have a webservice, with policy, etc. annotations, and you go to the WSDL URL (http://yourhost/your_webservice_uri?WSDL, you'll get a 'dynamic' WSDL, which incorporates things like policy files, etc. that get pulled in by things like the "@policy" annotation. 

    A WSDL that you get generated using, for example, by using Workshop won't have that policy stuff in the WSDL.

    So, to answer Ole's question, you'd need to build your webservice with the @RolesAllowed at the class level, deploy it, then point your browser to the ?WSDL URL, to get 1 WSDL.

    Then, you'd need to modify your webservice code to put the @RolesAllowed at the operation/method level, rebuild the EAR, re-deploy it, then point your browser to the ?WSDL URL again, to get the 2nd WSDL.

    Those are the two WSDLs that he's looking for, I think.

    BTW, when you try to use SOAPUI, I think (not sure) that you'd need to import the appropriate WSDL.

    Jim
  • Thanks for the clarification.
    There is no difference in the two WSDLs created dynamically.
    However, one difference is that when I request the WSDL from the browser, for the version of the webservice with roles at method level, I don't get prompted for username/password, while I get prompted for username/password when I request from the browser the WSDL for the webservice with roles at class level.

    Thanks, Mariateresa
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    SmartBear Alumni (Retired)
    Hi,

    ok.. then maybe you just need to add username/password credentials in the AUT tab under the request and also enable preemptive authentication in the global HTTP Preferences!?

    regards!

    /Ole
    eviware.com
  • JimL's avatar
    JimL
    Contributor
    Mariateresa wrote:

    Thanks for the clarification.
    There is no difference in the two WSDLs created dynamically.
    However, one difference is that when I request the WSDL from the browser, for the version of the webservice with roles at method level, I don't get prompted for username/password, while I get prompted for username/password when I request from the browser the WSDL for the webservice with roles at class level.

    Thanks, Mariateresa


    Hi,

    I'm assuming that when you said that you "get prompted for username/password", you mean that you get a popup login window?  If that's the case, and while I don't really understand why you'd get the popup in one case versus the other, you might try what is suggested here:

    http://reference.mapinfo.com/software/e ... -2-07.html

    i.e., add:

    false

    to your config.xml. 

    You'll need to bounce the WebLogic domain/admin server after making that change.

    I had that (popup) happen when I was doing some testing with trying to get message-level username/password token working with WebLogic.

    Like I said, it doesn't make sense to me that you'd get it with the @RolesAllowed at one place vs. the other, but give it a try.

    Hope that this helps.

    Jim