DigestAuthTest is failing on 2.3.x
Hi, Just spotted : https://hudson.apache.org/hudson/job/CXF-Trunk-JDK15/org.apache.cxf$cxf-rt-transports-http/1577/testReport/org.apache.cxf.transport.http/DigestAuthSupplierTest/testEncode/ Does someone know what can be causing it ? cheers, Sergey
Re: wsdl2java version 2.3.1
On Wednesday 15 December 2010 4:21:16 am aaa aaa wrote:
> I see.
>
> Version 2.3.1 add this endorsed dir, which explain why the wsdl2java tool
> generate 2.2 compliant code.
>
> Problem come from the ant build.xml file. It doesn't include the endorsed
> dir in the classpath for compile task.
> This occure for both my custom build.xml (sounds logical as it didn't exist
> in 2.3.0) but also for the auto-generated build file.
>
> Quick fix is to either to remove the jar of the endorsed dir so the code is
> 2.1 compliant as you stated, either to fix after generation the build file
> to add the endorsed dir to classpath.
AH!!! The generated build.xml file. Now I get it. Yep. That's a bug.
The samples all use a common_build.xml that is fine.Now I understand it
and can reproduce.
Thanks!
Dan
>
> Thanks for your help.
>
> Kayser
>
> 2010/12/14 Daniel Kulp
>
> > You don't NEED to move to java 7. There are two options:
> >
> > 1) Endorse the jars in the lib/endorsed directory. That upgrades the
> > apis that are picked up to 2.2 level. The wsdl2java script does that
> > so they are
> > picked up. When found, the tool generates 2.2 compiant code and thus
> > would need to have the 2.2 jars endorsed to be compilable.
> >
> > 2) Remove the jars in the endorsed dir. In that case, it would pick up
> > the
> > 2.1 level version built into the JDK and it will generate 2.1 compliant
> > code
> > and compilable without endorsing anything.
> >
> > The endorsement of the jars is mentioned in the migration guide:
> > http://cxf.apache.org/docs/23-migration-guide.html
> >
> >
> > Dan
> >
> > On Tuesday 14 December 2010 11:19:38 am aaa aaa wrote:
> > > Hello,
> > >
> > > I am new to Apache CXF. I tried it few months ago with Apache CXF
> > > 2.3.0, with a contract first approach.
> > >
> > > Now that the version 2.3.1 is released, I used again the wsdl2java
> > > tools
> >
> > to
> >
> > > check for differences.
> > > I encounter a compilation error on the generated Service class.
> > >
> > > This come from the new features:
> > > public SwafeService(WebServiceFeature ... features) {
> > >
> > > super(WSDL_LOCATION, SERVICE, features);
> > >
> > > }
> > > public SwafeService(URL wsdlLocation, WebServiceFeature ...
> > > features)
> >
> > {
> >
> > > super(wsdlLocation, SERVICE, features);
> > >
> > > }
> > >
> > > public SwafeService(URL wsdlLocation, QName serviceName,
> > >
> > > WebServiceFeature ... features) {
> > >
> > > super(wsdlLocation, serviceName, features);
> > >
> > > }
> > >
> > > I have resolved the problem by switching to a Java 7 JVM or deleting
> > > this generated code.
> > >
> > > It would be good to add a notification/warning on the wdsl2java tool
> > > page and/or on the changelog. I think migration from Java 5 to Java 7
> > > is a big change that would deserve it.
> > >
> > > Or maybe rather put an option in the wsdl2java tool to explicitly add
> > > or not this new feature.
> > >
> > > Regards,
> > >
> > > Kayser
> >
> > --
> > Daniel Kulp
> > dk...@apache.org
> > http://dankulp.com/blog
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Re: DigestAuthTest is failing on 2.3.x
On Thursday 16 December 2010 11:59:18 am Sergey Beryozkin wrote: > Hi, > > Just spotted : > > https://hudson.apache.org/hudson/job/CXF-Trunk-JDK15/org.apache.cxf$cxf-rt- > transports-http/1577/testReport/org.apache.cxf.transport.http/DigestAuthSup > plierTest/testEncode/ > > Does someone know what can be causing it ? Seems to be passing now. Not really sure. Dan > > cheers, Sergey -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
Re: DigestAuthTest is failing on 2.3.x
Hi Sergey, I wrote the test but it was not correct. I write the digest auth token from a hashmap. The test compared the result string with an expected string. Seems for hashmap this is not always working. So I corrected the test by parsing the token into a map and comparing two maps. That seems to work reliably. Btw. Before there was no real test of DigestAuth at all. I would like to also create an integration test for digest auth. Does anyone have a good idea how to do this? Is it possible to start embedded jetty with digest auth? Best regards Christian Am 16.12.2010 17:59, schrieb Sergey Beryozkin: Hi, Just spotted : https://hudson.apache.org/hudson/job/CXF-Trunk-JDK15/org.apache.cxf$cxf-rt-transports-http/1577/testReport/org.apache.cxf.transport.http/DigestAuthSupplierTest/testEncode/ Does someone know what can be causing it ? cheers, Sergey -- http://www.liquid-reality.de
Re: DigestAuthTest is failing on 2.3.x
Hi Christian On Thu, Dec 16, 2010 at 9:50 PM, Christian Schneider < ch...@die-schneider.net> wrote: > Hi Sergey, > > I wrote the test but it was not correct. I write the digest auth token from > a hashmap. The test compared the result string with an expected string. > Seems for hashmap this is not always working. > So I corrected the test by parsing the token into a map and comparing two > maps. That seems to work reliably. > > I've had quite a few tests failing in a similar way too :-) > Btw. Before there was no real test of DigestAuth at all. I would like to > also create an integration test for digest auth. Does anyone have a good > idea how to do this? Is it possible to start embedded jetty with digest > auth? > > I've written recently two Jetty-based system tests relying on Jetty security features, one is to do with Jetty providing the container-managed authentication. For example, see http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/security/JAXRSSimpleSecurityTest.java It is a JAX-RS test but you can probably just copy & paste it into systests/jaxws, as well as test/resources/jaxrs_simple_security folder (into say jaxws_digest) and just updates beans.xml (more on it below). But this code http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/security/BookServerSimpleSecurity.java is probably of main interest, there we tell Jetty where the jetty-realm.properties file http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/security/jetty-realm.properties is located. So the only other thing to do is to have web.xml require the DIGEST auth, I guess you just need to replace BASIC with DIGEST in http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/resources/jaxrs_simple_security/WEB-INF/web.xml Note - the security-constraint section is commented out because I do not want Jetty to enforce the user is in a certain role bur rather want CXF interceptors to enforce it, I only want jetty to populate the current principal (name, roles). Finally, you can have in your beans,xml just a single JAX-WS endpoint, similar to the jaxrs endpoint with the /security1 address, just have the SimpleAuthrorizingInterceptor registered only http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/resources/jaxrs_simple_security/WEB-INF/beans.xml A test like this can verify that the container is capable of processing the digest auth Authorization, and that CXF can enforce the container-populated rules on a per-endpoint basis...You can simplify it a lot, omit the authorization part, etc Hope it helps, Sergey > Best regards > > Christian > > > Am 16.12.2010 17:59, schrieb Sergey Beryozkin: > > Hi, >> >> Just spotted : >> >> >> https://hudson.apache.org/hudson/job/CXF-Trunk-JDK15/org.apache.cxf$cxf-rt-transports-http/1577/testReport/org.apache.cxf.transport.http/DigestAuthSupplierTest/testEncode/ >> >> Does someone know what can be causing it ? >> >> cheers, Sergey >> >> > -- > > http://www.liquid-reality.de > >
Discussion: Design of http authentication
Hi all,
I am currently trying to make the authentication in HttpConduit more
flexible.
In the following thread I already discussed with Dan to use a strategy
pattern:
http://cxf.547215.n5.nabble.com/Re-Discuss-change-http-authorization-handling-to-be-strategy-based-td3266405.html#none
So my current goals / requirements are:
1) Move as much auth stuff out of HttpConduit as possible
2) Handle proxy authentication and server authentication in the same way
3) The authentication implementations should not know too much of their
environment. (Currently the calls on HttpAuthSupplier use HttpConduit
and Message which is too much knowledge in my opinion)
4) Configuration handling and overrides should be outside of the
mechansim implementation if possible. So for example today the
DigestAuthSupplier decides if it uses the config from the conduit or the
message.
5) The authentication support should be flexible enough for challenge
based authentications like NTLM that need several challenge/response
exchanges
6) The authentication should support streaming whenever possible
7) Basic auth should be easy to setup
8) Only one mechanism will be set up in the config per conduit. It is
not necessary to have several in parallel with fallbacks
These goals are not possible to achieve with the current
HttpAuthSupplier interface.
So my first question is: How important is the current HttpAuthSupplier
interface? Is it ok to change it? Do we need a deprecation phase?
The other topic is to discuss my idea for a interface. I have attached
my design below.
The idea is to have a HttpClientAuthenticationProvider imlementation
that is selected by the mechanism name it supports. The implementation
will be
instantiated by conduit (no singleton so it can hold authentication
state). The AuthenticationProvider delegates finding the username
password combination
to use to a CredentialsProvider. The simplest form is a provider that
always delivers the same username and password and is configured from
AuthorizationPolicy of conduit.
I would be happy to hear some opinions and suggestions about the design.
Currently the design does not support our complicated override
possibilities. I have digged into the HttpConduit and found that
authorization information is currently drawn from the following sources:
- HttpConduit.authSupplier => only for server authentication
- HttpConduit.authorizationPolicy => for server authentication
- HttpConduit.proxyAuthorizationPolicy
- Message.AuthorizationPolicy => only for server auth, overrides conduit
authorizationPolicy
- Message.AUTH_VALUE => not exactly sure when this is used
- Message.AuthorizationPolicy.authorization => is used if set and no
username is given
I think this opens much too many possible ways to configure
authentication and I doubt that any user really understands when which
config is used. Still these ways can be configured today and I have no
idea how many
people use each style. For example the Negotiate / Kerberos
implementation I found on the net uses the last option.
So my question is do we need all these possible ways of configuration?
Best regards
Christian
---
/**
* Authentication provider for a HttpConduit.
* Each authentication provider supports one rfc2617 authentication
* mechanism.
*
* http://www.ietf.org/rfc/rfc2617.txt
*/
public interface HttpClientAuthenticationProvider {
void setCredentialsProvider(CredentialsProvider credentialsProvider);
/**
*
* @return authentication mechanism name supported by this
provider. May not return null
*/
String getMechanismName();
/**
* Processes the authentication token and returns the token
* to be sent to the counterpart
*
* @param url where we connect to
* @param requestMethod http request method that is used to access
the url
* @param token from WWW-Authenticate header
* @return token to be sent to counterpart for next try or null if
authentication is finished
*/
String processChallenge(URL url, String requestMethod, String token);
}
public interface CredentialsProvider {
/**
*
* @param url
* @param realm
* @return user name and password for the given realm or null if
none found
*/
UserAndPassword getCredentialsForUrlAndRealm(URL url, String realm);
}
--
http://www.liquid-reality.de
Does anybody also see OOBHeaderTest failure
Guys, I saw this failure today from my side, any guy else also saw it? Regards Freeman -- Freeman Fang FuseSource: http://fusesource.com blog: http://freemanfang.blogspot.com twitter: http://twitter.com/freemanfang Apache Servicemix:http://servicemix.apache.org Apache Cxf: http://cxf.apache.org Apache Karaf: http://karaf.apache.org Apache Felix: http://felix.apache.org
Re: Does anybody also see OOBHeaderTest failure
Hi, This test also failed on Hudson CI, so I investigate it a little bit and found that this commit[1] cause this problem. Before this change, the MustUnderstandEndingInterceptor is added for server side in any case, after this change, MustUnderstandEndingInterceptor is only added for server side when notUnderstandHeaders isn't empty. Not sure current logic is wrong or what we need is just refactor the wrong testcase. [1]http://svn.apache.org/viewvc/cxf/trunk/rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/MustUnderstandInterceptor.java?r1=1050165&r2=1050164&pathrev=1050165 Freeman On 2010-12-17, at 下午1:24, Freeman Fang wrote: Guys, I saw this failure today from my side, any guy else also saw it? Regards Freeman -- Freeman Fang FuseSource: http://fusesource.com blog: http://freemanfang.blogspot.com twitter: http://twitter.com/freemanfang Apache Servicemix:http://servicemix.apache.org Apache Cxf: http://cxf.apache.org Apache Karaf: http://karaf.apache.org Apache Felix: http://felix.apache.org -- Freeman Fang FuseSource: http://fusesource.com blog: http://freemanfang.blogspot.com twitter: http://twitter.com/freemanfang Apache Servicemix:http://servicemix.apache.org Apache Cxf: http://cxf.apache.org Apache Karaf: http://karaf.apache.org Apache Felix: http://felix.apache.org
