Loading ...
Sorry, an error occurred while loading the content.

SOAP Extension for Digest Authentication

Expand Messages
  • Bob Cunnings
    Hello, A draft specification for a SOAP Extension (Module) implementing a digest authentication scheme is presented at:
    Message 1 of 8 , Sep 2 9:57 PM
    • 0 Attachment
      Hello,

      A draft specification for a SOAP Extension (Module) implementing a digest
      authentication scheme is presented at:

      http://www.whitemesa.com/digauthmod.html

      for the purpose of soliciting comments and criticism. The proposed scheme is
      an adaptation of the mechanism defined in RFC 2617. The specification is
      somewhat skimpy at this point.

      This are many applications where a lightweight authentication scheme like
      this is quite adequate to control access to SOAP services. Since it is such
      a basic building block, I hope that a standard SOAP Extension for simple
      digest authentication is adopted. This would be a boon to interoperability
      between SOAP service implementations requiring this functionality. This type
      of scheme has proven very useful here in practice, in the deployment of
      "authentication gateways" to SOAP services, etc.

      A live endpoint supporting the proposed SOAP Extension is available at:
      http://www.whitemesa.net/interop/std/digauthtest for testing purposes.

      The WSDL document describing the service at this endpoint is at:
      http://www.whitemesa.net/wsdl/std/soapdigauthtest.wsdl

      A browser based test client for exercising the service is available at:
      http://www.whitemesa.net/std/digauth/echoStringAuth.htm

      This represents a natural use of the SOAP Extension mechanism, and addresses
      a rather common application requirement. The proposal is intended to serve
      as a starting point, for discussion if nothing else.

      RC
    • Rich Salz
      My first reaction based on skimming the spec: I d like to see E01...E05, S01, etc., replaced with a string that looks more like the specified SOAP faults,
      Message 2 of 8 , Sep 3 6:42 PM
      • 0 Attachment
        My first reaction based on skimming the spec: I'd like to see
        E01...E05, S01, etc., replaced with a string that looks more like the
        specified SOAP faults, Digest.BadRealm, for example. Or
        Digest:BadRealm, where the fault code is a QNAME not a string. :)

        Your document should have a couple of sentences about the (non-)impact
        of actors, the risk of itnermediates stripping the headers out, etc.

        /r$


        Bob Cunnings wrote:
        >
        > Hello,
        >
        > A draft specification for a SOAP Extension (Module) implementing a
        > digest
        > authentication scheme is presented at:
        >
        > http://www.whitemesa.com/digauthmod.html
        >
        > for the purpose of soliciting comments and criticism. The proposed
        > scheme is
        > an adaptation of the mechanism defined in RFC 2617. The specification
        > is
        > somewhat skimpy at this point.
        >
        > This are many applications where a lightweight authentication scheme
        > like
        > this is quite adequate to control access to SOAP services. Since it is
        > such
        > a basic building block, I hope that a standard SOAP Extension for
        > simple
        > digest authentication is adopted. This would be a boon to
        > interoperability
        > between SOAP service implementations requiring this functionality.
        > This type
        > of scheme has proven very useful here in practice, in the deployment
        > of
        > "authentication gateways" to SOAP services, etc.
        >
        > A live endpoint supporting the proposed SOAP Extension is available
        > at:
        > http://www.whitemesa.net/interop/std/digauthtest for testing purposes.
        >
        > The WSDL document describing the service at this endpoint is at:
        > http://www.whitemesa.net/wsdl/std/soapdigauthtest.wsdl
        >
        > A browser based test client for exercising the service is available
        > at:
        > http://www.whitemesa.net/std/digauth/echoStringAuth.htm
        >
        > This represents a natural use of the SOAP Extension mechanism, and
        > addresses
        > a rather common application requirement. The proposal is intended to
        > serve
        > as a starting point, for discussion if nothing else.
        >
        > RC
        >
        > -----------------------------------------------------------------
        > This group is a forum for builders of SOAP implementations to discuss
        > implementation and interoperability issues. Please stay on-topic.
        >
        > To unsubscribe from this group, send an email to:
        > soapbuilders-unsubscribe@yahoogroups.com
        >
        > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

        --
        Zolera Systems, Securing web services (XML, SOAP, Signatures,
        Encryption)
        http://www.zolera.com
      • Bob Cunnings
        Hello, Yes, the Status codes are holdovers from previous implementation efforts, and are too cryptic. I have resolved to change the type of the element to
        Message 3 of 8 , Sep 3 8:04 PM
        • 0 Attachment
          Hello,

          Yes, the Status codes are holdovers from previous implementation efforts,
          and are too cryptic.
          I have resolved to change the type of the element to "xsd:QName", (like the
          "faultcode" element in SOAP 1.1) and use descriptive names qualified by the
          spec's namespace URI.

          The subject of header targeting is touched on briefly in the intro, but the
          processing rules need to discuss contingencies such as the loss of the
          header entry. For instance, request messages arriving without their header
          entries simply look like initial requests, and will result in the usual
          challenge in the response. This could result in a loop if the client
          persists in attempting the request in the face of repeated challenges. At
          the moment the processing rules don't say anything about the clients
          behavior in the face header loss, etc. This is an area that needs to be
          expanded.

          Thanks,

          RC


          > My first reaction based on skimming the spec: I'd like to see
          > E01...E05, S01, etc., replaced with a string that looks more like the
          > specified SOAP faults, Digest.BadRealm, for example. Or
          > Digest:BadRealm, where the fault code is a QNAME not a string. :)
          >
          > Your document should have a couple of sentences about the (non-)impact
          > of actors, the risk of itnermediates stripping the headers out, etc.
          >
          > /r$
          >
          >
          > Bob Cunnings wrote:
          > >
          > > Hello,
          > >
          > > A draft specification for a SOAP Extension (Module) implementing a
          > > digest
          > > authentication scheme is presented at:
          > >
          > > http://www.whitemesa.com/digauthmod.html
          > >
          > > for the purpose of soliciting comments and criticism. The proposed
          > > scheme is
          > > an adaptation of the mechanism defined in RFC 2617. The specification
          > > is
          > > somewhat skimpy at this point.
          > >
          > > This are many applications where a lightweight authentication scheme
          > > like
          > > this is quite adequate to control access to SOAP services. Since it is
          > > such
          > > a basic building block, I hope that a standard SOAP Extension for
          > > simple
          > > digest authentication is adopted. This would be a boon to
          > > interoperability
          > > between SOAP service implementations requiring this functionality.
          > > This type
          > > of scheme has proven very useful here in practice, in the deployment
          > > of
          > > "authentication gateways" to SOAP services, etc.
          > >
          > > A live endpoint supporting the proposed SOAP Extension is available
          > > at:
          > > http://www.whitemesa.net/interop/std/digauthtest for testing purposes.
          > >
          > > The WSDL document describing the service at this endpoint is at:
          > > http://www.whitemesa.net/wsdl/std/soapdigauthtest.wsdl
          > >
          > > A browser based test client for exercising the service is available
          > > at:
          > > http://www.whitemesa.net/std/digauth/echoStringAuth.htm
          > >
          > > This represents a natural use of the SOAP Extension mechanism, and
          > > addresses
          > > a rather common application requirement. The proposal is intended to
          > > serve
          > > as a starting point, for discussion if nothing else.
          > >
          > > RC
          > >
          > > -----------------------------------------------------------------
          > > This group is a forum for builders of SOAP implementations to discuss
          > > implementation and interoperability issues. Please stay on-topic.
          > >
          > > To unsubscribe from this group, send an email to:
          > > soapbuilders-unsubscribe@yahoogroups.com
          > >
          > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
          >
          > --
          > Zolera Systems, Securing web services (XML, SOAP, Signatures,
          > Encryption)
          > http://www.zolera.com
          >
        • Simon Fell
          Bob, other than transport independence [which is good], do you see any other advantages over a transport provided authentication system ? Thanks Simon
          Message 4 of 8 , Sep 4 3:07 PM
          • 0 Attachment
            Bob, other than transport independence [which is good], do you see any
            other advantages over a transport provided authentication system ?

            Thanks
            Simon


            On Sun, 2 Sep 2001 22:57:01 -0600, in soap you wrote:

            >Hello,
            >
            >A draft specification for a SOAP Extension (Module) implementing a digest
            >authentication scheme is presented at:
            >
            >http://www.whitemesa.com/digauthmod.html
            >
            >for the purpose of soliciting comments and criticism. The proposed scheme is
            >an adaptation of the mechanism defined in RFC 2617. The specification is
            >somewhat skimpy at this point.
            >
            >This are many applications where a lightweight authentication scheme like
            >this is quite adequate to control access to SOAP services. Since it is such
            >a basic building block, I hope that a standard SOAP Extension for simple
            >digest authentication is adopted. This would be a boon to interoperability
            >between SOAP service implementations requiring this functionality. This type
            >of scheme has proven very useful here in practice, in the deployment of
            >"authentication gateways" to SOAP services, etc.
            >
            >A live endpoint supporting the proposed SOAP Extension is available at:
            >http://www.whitemesa.net/interop/std/digauthtest for testing purposes.
            >
            >The WSDL document describing the service at this endpoint is at:
            >http://www.whitemesa.net/wsdl/std/soapdigauthtest.wsdl
            >
            >A browser based test client for exercising the service is available at:
            >http://www.whitemesa.net/std/digauth/echoStringAuth.htm
            >
            >This represents a natural use of the SOAP Extension mechanism, and addresses
            >a rather common application requirement. The proposal is intended to serve
            >as a starting point, for discussion if nothing else.
            >
            >RC
            >
            >
            >
            >
            >
            >-----------------------------------------------------------------
            >This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues. Please stay on-topic.
            >
            >To unsubscribe from this group, send an email to:
            >soapbuilders-unsubscribe@yahoogroups.com
            >
            >
            >
            >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            >
          • Rich Salz
            ... The primary advantage is that you can KEEP the authentication with the application. If I want to prove client identity with SSL, I ahve to preserve all SSL
            Message 5 of 8 , Sep 4 5:48 PM
            • 0 Attachment
              > Bob, other than transport independence [which is good], do you see any
              > other advantages over a transport provided authentication system ?

              The primary advantage is that you can KEEP the authentication with the
              application. If I want to prove client identity with SSL, I ahve to
              preserve all SSL traffic. Ugh. If I want to prove identity with a SOAP
              message that has signed XML, I need only keep the app data.
              /r$
              --
              Zolera Systems, Securing web services (XML, SOAP, Signatures,
              Encryption)
              http://www.zolera.com
            • Bob Cunnings
              Hello, Well, yes, although transport independence is the main objective. It allows the authentication protocol to be tunneled through intermediate SOAP
              Message 6 of 8 , Sep 4 7:12 PM
              • 0 Attachment
                Hello,

                Well, yes, although transport independence is the main objective.

                It allows the authentication protocol to be tunneled through
                intermediate SOAP processors, who aren't the target of the
                authentication header entry. If you desire that the client be
                authenticated to the endpoint, for instance, but the message may
                pass through SOAP *processing* intermediaries, using transport
                level services might be tricky or impossible, since they typically
                operate on a hop by hop basis (e.g. RFC 2617 over HTTP,
                disregarding proxies).

                There's a small benefit in that it works around transport nodes that
                don't support authentication anyway, e.g. simple HTTP listeners
                that don't support RFC2617.

                RC


                > Bob, other than transport independence [which is good], do you see any
                > other advantages over a transport provided authentication system ?
                >
                > Thanks
                > Simon
                >
                >
                > On Sun, 2 Sep 2001 22:57:01 -0600, in soap you wrote:
                >
                > >Hello,
                > >
                > >A draft specification for a SOAP Extension (Module) implementing a digest
                > >authentication scheme is presented at:
                > >
                > >http://www.whitemesa.com/digauthmod.html
                > >
                > >for the purpose of soliciting comments and criticism. The proposed scheme is
                > >an adaptation of the mechanism defined in RFC 2617. The specification is
                > >somewhat skimpy at this point.
                > >
                > >This are many applications where a lightweight authentication scheme like
                > >this is quite adequate to control access to SOAP services. Since it is such
                > >a basic building block, I hope that a standard SOAP Extension for simple
                > >digest authentication is adopted. This would be a boon to interoperability
                > >between SOAP service implementations requiring this functionality. This type
                > >of scheme has proven very useful here in practice, in the deployment of
                > >"authentication gateways" to SOAP services, etc.
                > >
                > >A live endpoint supporting the proposed SOAP Extension is available at:
                > >http://www.whitemesa.net/interop/std/digauthtest for testing purposes.
                > >
                > >The WSDL document describing the service at this endpoint is at:
                > >http://www.whitemesa.net/wsdl/std/soapdigauthtest.wsdl
                > >
                > >A browser based test client for exercising the service is available at:
                > >http://www.whitemesa.net/std/digauth/echoStringAuth.htm
                > >
                > >This represents a natural use of the SOAP Extension mechanism, and addresses
                > >a rather common application requirement. The proposal is intended to serve
                > >as a starting point, for discussion if nothing else.
                > >
                > >RC
                > >
                > >
                > >
                > >
                > >
                > >-----------------------------------------------------------------
                > >This group is a forum for builders of SOAP implementations to discuss implementation and interop
                erability issues. Please stay on-topic.
                > >
                > >To unsubscribe from this group, send an email to:
                > >soapbuilders-unsubscribe@yahoogroups.com
                > >
                > >
                > >
                > >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                > >
                >
                >
                >
                > -----------------------------------------------------------------
                > This group is a forum for builders of SOAP implementations to discuss implementation and interope
                rability issues. Please stay on-topic.
                >
                > To unsubscribe from this group, send an email to:
                > soapbuilders-unsubscribe@yahoogroups.com
                >
                >
                >
                > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                >
              • Dirk-Willem van Gulik
                ... On the other hand - if I am a firewall/securing box and my task is to ensure that no unencrypted traffic - or traffic not accompanied by a x509 signed by a
                Message 7 of 8 , Sep 4 9:05 PM
                • 0 Attachment
                  On Tue, 4 Sep 2001, Rich Salz wrote:

                  > > Bob, other than transport independence [which is good], do you see any
                  > > other advantages over a transport provided authentication system ?
                  >
                  > The primary advantage is that you can KEEP the authentication with the
                  > application. If I want to prove client identity with SSL, I ahve to
                  > preserve all SSL traffic. Ugh. If I want to prove identity with a SOAP
                  > message that has signed XML, I need only keep the app data.

                  On the other hand - if I am a firewall/securing box and my task is to
                  ensure that no unencrypted traffic - or traffic not accompanied by a x509
                  signed by a trusted party goes out - my job is a lot easier on the
                  transport layer (and I have the infrastructure in place).

                  That on XML payload level you do more is nice - but legacy investments,
                  legacy policies or things like FDC/FCIC rules are propably going to
                  require me to do the same on the transport layer.

                  Dw


                  --A011YHh00446.5667/mobile.webweaving.org--


                  --A011YHi00446.5667/mobile.webweaving.org--
                  ReSent-Date: Wed, 5 Sep 2001 17:27:08 -0700 (PDT)
                  ReSent-From: Dirk-Willem van Gulik <dirkx@...>
                  ReSent-To: <soapbuilders@yahoogroups.com>
                  ReSent-Subject: Re: [soapbuilders] SOAP Extension for Digest Authentication
                  ReSent-Message-ID: <Pine.OSX.4.33.0109051727080.496@...>



                  On Tue, 4 Sep 2001, Rich Salz wrote:

                  > > Bob, other than transport independence [which is good], do you see any
                  > > other advantages over a transport provided authentication system ?
                  >
                  > The primary advantage is that you can KEEP the authentication with the
                  > application. If I want to prove client identity with SSL, I ahve to
                  > preserve all SSL traffic. Ugh. If I want to prove identity with a SOAP
                  > message that has signed XML, I need only keep the app data.

                  On the other hand - if I am a firewall/securing box and my task is to
                  ensure that no unencrypted traffic - or traffic not accompanied by a x509
                  signed by a trusted party goes out - my job is a lot easier on the
                  transport layer (and I have the infrastructure in place).

                  That on XML payload level you do more is nice - but legacy investments,
                  legacy policies or things like FDC/FCIC rules are propably going to
                  require me to do the same on the transport layer.

                  Dw


                  --A011YHh00446.5667/mobile.webweaving.org--


                  --A011YHi00446.5667/mobile.webweaving.org--
                • Rich Salz
                  Not sure what FDC FIDC rules are, but it s awfully hard to get transport-level nonrepudiation and end-to-end security. I predict folks will do it at the
                  Message 8 of 8 , Sep 5 6:03 PM
                  • 0 Attachment
                    Not sure what FDC FIDC rules are, but it's awfully hard to get
                    transport-level nonrepudiation and end-to-end security.

                    I predict folks will do it at the transport level because SSL is
                    "easy." The more important apps will do it at the app level, too.
                    /r$
                    --
                    Zolera Systems, Securing web services (XML, SOAP, Signatures,
                    Encryption)
                    http://www.zolera.com
                  Your message has been successfully submitted and would be delivered to recipients shortly.