Announcement Announcement Module
Collapse
No announcement yet.
Extract only ws-sec portion that works with acegi? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Extract only ws-sec portion that works with acegi?

    I write applications in an ESB-like framework that uses Spring and Maven1, running in WebLogic 8.1.4. We don't use Axis on the server side, we just have a custom HTTP listener that dispatches to a bean based on a SOAP address header.

    I apologize if I'm asking trivial questions about Spring-WS and Acegi, I'm just today starting to examine these two packages.

    Up to this point, we haven't had to implement security for any services. However, I'm going to have to do this soon for some specific services. I can see that using Acegi to implement Basic auth against our LDAP will be pretty straightforward. However, I'd like to consider the possibility of using WS-Security, UserNameToken at least. Acegi doesn't provide this, but I imagine that Spring-WS does. However, I can't use all of Spring-WS, as I can't replace our listeners our dispatching system.

    Is it possible to just use the WS-Security portion of Spring-WS, which plugs into Acegi, to authenticate and authorize web services?

    If that's the case, is the WS-Security implementation in M1 and the upcoming M2 solid enough to consider using for this?

  • #2
    Originally posted by dkarr
    Is it possible to just use the WS-Security portion of Spring-WS, which plugs into Acegi, to authenticate and authorize web services?
    This is partially possible. The WS-Security security solution of Spring-WS is based on XWSS (XML Web Service Security), from SUN. It's also a part of the Java Web Service Developer pack.

    The XwssSecurityInterceptor in Spring-WS is basically a thin wrapper around it. XWSS is based on SAAJ (javax.xml.soap.*), so you will have to create SAAJ messages based on the incoming message.

    Using XWSS, you can use the callbacks in org.springframework.ws.soap.security.xwss.callback , including the Acegi callbacks in org.springframework.ws.soap.security.xwss.callback .acegi. Refer to the reference manual, and the JWDSP tutorial for more information.

    Originally posted by dkarr
    If that's the case, is the WS-Security implementation in M1 and the upcoming M2 solid enough to consider using for this?
    XWSS is quite stable, it forms the basis for Glassfish.

    Comment


    • #3
      Oh. That sounded promising, until you said it's based on the JWSDP. WebLogic 8.1.4 is hardwired to JWSDP 1.1, ancient history. I tried at one time to get it to use a newer version, but I gave up. I would be very surprised if I could get this to work with JWSDP 1.1 under the covers.

      Comment


      • #4
        Well, I don't think JWSDP had XWSS as part of it. So you're not overriding it, you're just using it. Basically, you have to make sure that the jars in WEB-INF/lib are used, instead of Weblogic's version. You can do this by putting the following in WEB-INF:

        Code:
        <weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90">
          <container-descriptor>
            <prefer-web-inf-classes>true</prefer-web-inf-classes>
          </container-descriptor>
        </weblogic-web-app>
        The above is for WL 9.1, but the same can be done in 8.1. The key is prefer-web-inf-classes.

        Comment


        • #5
          It's JWSDP that I need to override, and yes, I know about "prefer-web-inf-classes", it just doesn't work for this. First of all, that only works for a webapp, not an ear. The XWSS web page states it depends on SAAJ 1.3 (the JWSDP in WLS 8.1.4 is older than that), so this will definitely be a problem.

          Comment


          • #6
            As an alternative, you might want to check out WSS4J, which is another WS-Security implementation. As far as I know, it has no Acegi integration though.

            Finally, you might want to consider creating your own solution, especially if you're only interested in the the Username profile, which is the easiest part of the spec. Basically, you can write a XPath query which extracts the username + password from the message, and give that to Acegi. The Spring-WS & Acegi source code can show you how.

            Hope this helps,

            Comment


            • #7
              Using WS-Security under Weblogic 10 (signature)

              I've read this post and also the one from BEA. I think my problem is related to SAAJ, but no suggested configuration (here or there) works. I receive this exception:

              Code:
              java.lang.AssertionError: UNIMPLEMENTED
                      at weblogic.xml.domimpl.DocumentImpl.getElementsByTagNameNS(DocumentImpl.java:401)
                      at weblogic.xml.saaj.SOAPPartImpl.getElementsByTagNameNS(SOAPPartImpl.java:258)
                      at com.sun.xml.wss.impl.dsig.WSSPolicyConsumerImpl.generateReferenceList(WSSPolicyConsumerImpl.java:584)
                      at com.sun.xml.wss.impl.dsig.WSSPolicyConsumerImpl.generateSignedInfo(WSSPolicyConsumerImpl.java:345)
                      at com.sun.xml.wss.impl.dsig.WSSPolicyConsumerImpl.constructSignedInfo(WSSPolicyConsumerImpl.java:161)
              Any idea?

              Thanks.

              Comment


              • #8
                Weblogic 10 signature solved

                I have SAAJ 1.3 libraries on my APP-INF/lib directory and I've included these lines on my context:

                Code:
                <bean id="messageFactory" class="org.springframework.ws.soap.saaj.SaajSoapMessageFactory">
                        <property name="messageFactory">
                            <bean class="com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl"></bean>
                        </property>
                    </bean>
                It works, but I don't understand why. It seems like declaring SAAJ 1.1. usage?

                I'm also using XWSS 3.0 (xws-security-3.0.jar, xmlsec-1.3.jar and xmldsig-1.0.2.jar). Anyway it was a BEA configuration problem, no related to Spring WS.

                Comment


                • #9
                  No, the ver1_1 indicates the SOAP version, not the SAAJ version.

                  Comment

                  Working...
                  X