CXF
  1. CXF
  2. CXF-3216

Refactor http authentication to make it more flexible and simpler

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.3.1
    • Fix Version/s: 2.4
    • Component/s: Transports
    • Labels:
      None

      Description

      The http authentication should be completely based on authSupplier. The HttpConduit should simply delegate to it.
      We should also remove some of the other auth config options besides authorizationPolicy on conduit.

      1. CXF-3216-2.patch
        71 kB
        Christian Schneider
      2. CXF-3216-1.patch
        38 kB
        Christian Schneider

        Issue Links

          Activity

          Hide
          Jason Chen added a comment -

          Thanks for confirming Daniel.Do you have the JIRA# you mentioned above?

          Show
          Jason Chen added a comment - Thanks for confirming Daniel.Do you have the JIRA# you mentioned above?
          Hide
          Daniel Kulp added a comment -

          Christians note was that Kerberos auth was working at the transport level. Basically, using it for https authentication. What you are asking for is message level auth which is a bit different. A this point, we don't support kerberos in the WS-SecPol engine. Patches that would get us there are more than welcome. (new JIRA's of course)

          Basically, step one WOULD be a PolicyBuilder and Token object. That would allow us to parse the policy. Next would likely be updates to the PolicyBasedWSS4J*Interceptor to handle that token type.

          I DON'T know if this will also require some updates to WSS4J. There is a JIRA open there about Kerberos support where a user was going to supply a patch, but they never did.

          Show
          Daniel Kulp added a comment - Christians note was that Kerberos auth was working at the transport level. Basically, using it for https authentication. What you are asking for is message level auth which is a bit different. A this point, we don't support kerberos in the WS-SecPol engine. Patches that would get us there are more than welcome. (new JIRA's of course) Basically, step one WOULD be a PolicyBuilder and Token object. That would allow us to parse the policy. Next would likely be updates to the PolicyBasedWSS4J*Interceptor to handle that token type. I DON'T know if this will also require some updates to WSS4J. There is a JIRA open there about Kerberos support where a user was going to supply a patch, but they never did.
          Hide
          Jason Chen added a comment -

          Hi Christian, when you said Kerberos auth can now be configured, does that include the policy handler as well?
          I just looked at the nightly build source code and couldn't see how the SymmetricBindingHandler ever gets the KerberosToken or SpnegoToken since there is no token subclasses and builiders for these tokens.

          I quickly tried the latest snapshot for kerberos auth and got the following exception:
          Caused by: org.apache.cxf.ws.policy.PolicyException: No signature token
          at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:295)...

          which makes sense. I can see the SpnegoAuthSupplier executed and get the token from our KDC and inserted into the headers. So I tried disabling the the policy engine with "<p:engine enabled="false"></p:engine>" config and now get this exception:
          org.w3c.dom.DOMException: NOT_FOUND_ERR
          at weblogic.xml.domimpl.ParentNode.internalRemoveChild(ParentNode.java:317)
          at weblogic.xml.domimpl.ParentNode.removeChild(ParentNode.java:297)
          at weblogic.xml.domimpl.ElementBase.removeChild(ElementBase.java:24)
          at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:144)...

          Am I missing something obvious here? Will I need to implement the policy builder and token myself? I am new to this and happy to contribute if this hasn't been implemented, so any pointers are appreciated.

          Show
          Jason Chen added a comment - Hi Christian, when you said Kerberos auth can now be configured, does that include the policy handler as well? I just looked at the nightly build source code and couldn't see how the SymmetricBindingHandler ever gets the KerberosToken or SpnegoToken since there is no token subclasses and builiders for these tokens. I quickly tried the latest snapshot for kerberos auth and got the following exception: Caused by: org.apache.cxf.ws.policy.PolicyException: No signature token at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:295)... which makes sense. I can see the SpnegoAuthSupplier executed and get the token from our KDC and inserted into the headers. So I tried disabling the the policy engine with "<p:engine enabled="false"></p:engine>" config and now get this exception: org.w3c.dom.DOMException: NOT_FOUND_ERR at weblogic.xml.domimpl.ParentNode.internalRemoveChild(ParentNode.java:317) at weblogic.xml.domimpl.ParentNode.removeChild(ParentNode.java:297) at weblogic.xml.domimpl.ElementBase.removeChild(ElementBase.java:24) at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:144)... Am I missing something obvious here? Will I need to implement the policy builder and token myself? I am new to this and happy to contribute if this hasn't been implemented, so any pointers are appreciated.
          Hide
          Christian Schneider added a comment -

          The issue is fixed from my perspective

          Show
          Christian Schneider added a comment - The issue is fixed from my perspective
          Hide
          Christian Schneider added a comment -

          Committed another change to move auth stuff to a separate package. I also changed the interface of HttpAuthSupplier as we are incompatible after the move anyway.
          The change in the interface is not absolutely necessary. If there are objections I can roll back.

          Show
          Christian Schneider added a comment - Committed another change to move auth stuff to a separate package. I also changed the interface of HttpAuthSupplier as we are incompatible after the move anyway. The change in the interface is not absolutely necessary. If there are objections I can roll back.
          Hide
          Christian Schneider added a comment -
          • Replacing HttpConduit with AuthorizationPolicy in HttpAuthSupplier interface
            => This eliminates a circular dependency with HttpConduit and allows to reuse the interface for proxy auth
          • removed realm parameter from HttpAuthSupplier
            => The parameter is not necessary as the realm can always be extracted from the full auth token
          • Moving auth stuff into a package http.auth
            => As I change the interface and so loose backwards compatibility I also sorted the classes
          • Add proxyAuthSupplier in Httpcondduit and use it for proxy auth like authSupplier for serve auth
            => This change makes proxy auth and server auth very similar. Currently there is no retransmit for 407 reponses but it can easily added now. All one step authentications should work with this change already
          • Removed HttpBasicAuthSupplier
            => I hope this is ok. I doubt it was used frequently by customers anyway

          After this patch practically all auth stuff is moved out of HttpConduit. The bad thing is that HttpAuthSupplier is changed in an incompatible way. Is that ok or do we have to first deprecate the interface?

          Show
          Christian Schneider added a comment - Replacing HttpConduit with AuthorizationPolicy in HttpAuthSupplier interface => This eliminates a circular dependency with HttpConduit and allows to reuse the interface for proxy auth removed realm parameter from HttpAuthSupplier => The parameter is not necessary as the realm can always be extracted from the full auth token Moving auth stuff into a package http.auth => As I change the interface and so loose backwards compatibility I also sorted the classes Add proxyAuthSupplier in Httpcondduit and use it for proxy auth like authSupplier for serve auth => This change makes proxy auth and server auth very similar. Currently there is no retransmit for 407 reponses but it can easily added now. All one step authentications should work with this change already Removed HttpBasicAuthSupplier => I hope this is ok. I doubt it was used frequently by customers anyway After this patch practically all auth stuff is moved out of HttpConduit. The bad thing is that HttpAuthSupplier is changed in an incompatible way. Is that ok or do we have to first deprecate the interface?
          Hide
          Christian Schneider added a comment -

          I have now refactored the authentication of the http transport so the basic auth is now supported by DefaultBasicAuthSupplier. Spnego is now also supported using a SpnegoAuthSupplier.

          Basic, Digest and Spnego / Kerberos auth can now be configured by simply setting the AuthType in the AuthorizationPolicy. The HttpConduit then creates a HttpAuthSupplier on the fly if none is configured explicitly. Still an AuthoriationPolicy on the message overrides the AuthorizationPolicy on the Conduit.

          I have also added a system test for DigestAuthSupplier as I changed the code and wanted to make sure it really works against a jetty insstance.

          There are some possible compatibility issues with my patch:

          • The first thing is that the HttpAuthSupplier is cached so it is created only once. If you later change the Authtype the supplier will stay the same. This can be solved by deleting the authSupplier so it is recreated.
          • The HttpAuthsupplier now overrides the AuthorizationPolicy on the message. Before the AuthorizationPolicy on the message would override the AuthSupplier. I don´t think anyone really would use this
          • If the message content is to be cached is now only determined by calling the requiresRequestCaching method on the authsupplier. Before the authSupplier was also asked for premptiveAuthentication. If this did not return null the message was also cached. I think this is not necessary as the authsupplier can still decide if caching is needed.
          • Currently you can set authType and authorization on the authorizationPolicy. This is then used to directly create the authorization header. This is used by the old spnego interceptor I added recently. I removed this feature as it is only really usable in an interceptor and it can be done better by creating a custom authSupplier

          Additionally I would like to remove the feature of setting an AuthorizationPolicy on the message. This would allow us to make the authsuppliers independent of conduit and message in the future.

          I also would like to introduce an authSupplier for proxy auth and handling of 407 responses so we can support multi phase authentications with a proxy.

          Show
          Christian Schneider added a comment - I have now refactored the authentication of the http transport so the basic auth is now supported by DefaultBasicAuthSupplier. Spnego is now also supported using a SpnegoAuthSupplier. Basic, Digest and Spnego / Kerberos auth can now be configured by simply setting the AuthType in the AuthorizationPolicy. The HttpConduit then creates a HttpAuthSupplier on the fly if none is configured explicitly. Still an AuthoriationPolicy on the message overrides the AuthorizationPolicy on the Conduit. I have also added a system test for DigestAuthSupplier as I changed the code and wanted to make sure it really works against a jetty insstance. There are some possible compatibility issues with my patch: The first thing is that the HttpAuthSupplier is cached so it is created only once. If you later change the Authtype the supplier will stay the same. This can be solved by deleting the authSupplier so it is recreated. The HttpAuthsupplier now overrides the AuthorizationPolicy on the message. Before the AuthorizationPolicy on the message would override the AuthSupplier. I don´t think anyone really would use this If the message content is to be cached is now only determined by calling the requiresRequestCaching method on the authsupplier. Before the authSupplier was also asked for premptiveAuthentication. If this did not return null the message was also cached. I think this is not necessary as the authsupplier can still decide if caching is needed. Currently you can set authType and authorization on the authorizationPolicy. This is then used to directly create the authorization header. This is used by the old spnego interceptor I added recently. I removed this feature as it is only really usable in an interceptor and it can be done better by creating a custom authSupplier Additionally I would like to remove the feature of setting an AuthorizationPolicy on the message. This would allow us to make the authsuppliers independent of conduit and message in the future. I also would like to introduce an authSupplier for proxy auth and handling of 407 responses so we can support multi phase authentications with a proxy.

            People

            • Assignee:
              Christian Schneider
              Reporter:
              Christian Schneider
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development