Sorry, should be 'mvn install -Pfastinstall,jaxws22'
Cheers, Sergey On Thu, Apr 7, 2011 at 10:01 AM, Sergey Beryozkin <[email protected]>wrote: > Hi > > On Thu, Apr 7, 2011 at 9:53 AM, David Zhang <[email protected]> wrote: > >> Hello Sergey, >> >> i did my best to try that, but i ran into problems. >> >> First one is i cannot build the project. >> This documentation is not sufficient for me: >> http://cxf.apache.org/building.html >> Is there more extensive documentation somewhere? >> >> However, i downloaded the individual artifacts from Jenkins and patched my >> JBoss installation with them. >> >> To test the new snapshot release i changed my project to depend on the >> 2.3.4-SNAPSHOT version from the apache snapshots repository and rebuilt it. >> >> The second problem is the 2.3.4-SNAPSHOT is not compatible anymore with >> JBoss 6.0.0.Final. Cause of this is a package name changed from >> org.apache.cxf.jaxws22 to org.apache.cxf.jaxws. >> But JBoss has a class >> org.jboss.wsf.stack.cxf.deployment.EndpointImpl extends >> org.apache.cxf.jaxws22.EndpointImpl >> >> The result is i cannot deploy my project anymore. :-( >> >> > Just checkout CXF 2.3.4 using svn or git, and then do > > 'mvn install -Pfastinstall,jaxws' > > that should fix it > > Give it a try please > > Cheers, Sergey > > >> >> -----Ursprüngliche Nachricht----- From: Sergey Beryozkin >> Sent: Wednesday, April 06, 2011 6:39 PM >> To: [email protected] >> Subject: Re: UsernameToken JBoss Integration >> >> Hi David >> >> I did a minor update to WSS4JInInterceptor to ensure that the 'best' >> principal is wrapped as a SecurityContext principal, when possible. This >> update does not change the fact all Principals are still available on the >> message for subsequent interceptors to check, it simply attempts not to >> set >> a Principal representing the encryption key which was used to encrypt UT >> as >> the 'main' Principal. >> >> Hope Colm and others will be ok with this update. >> >> Can you please checkout 2.3.4-SNAPSHOT and verify it fixes the problem ? >> >> Thanks, Sergey >> >> On Tue, Apr 5, 2011 at 12:01 PM, David Zhang <[email protected]> wrote: >> >> Hello Sergey, >>> >>> i think i found the cause of the problem. JBoss 6.0.0.Final comes with >>> CXF >>> 2.3.1. However, i checked out the 2.3.3 tag and did a little bug fix. >>> >>> What do you think of it? Please tell me, if you will make a fix for >>> 2.3.x, >>> then i would like to download the update. >>> >>> Please look at >>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.doResults() >>> >>> At the end of the method is a for-loop over the wssEngineResults. If >>> withCallbacks is false then the UsernameToken should be put in the >>> message. >>> The Problem is, the first Principal found is not the >>> UsernameTokenPrincipal >>> but the DerivedKeyPrincipal. This triggers creation of a security context >>> and breakes the for-loop. The second wssEngineResult would have been the >>> UsernameTokenPrincipal. >>> >>> I believe this is the reason why i receive the error message: >>> Security Token is not available on the current message >>> >>> Here is the patch i use. It seems to work for me. >>> >>> David >>> >>> protected void doResults(SoapMessage msg, String actor, SOAPMessage doc, >>> Vector wsResult, >>> boolean utWithCallbacks) throws SOAPException, XMLStreamException, >>> WSSecurityException { >>> /* >>> * All ok up to this point. Now construct and setup the security >>> result >>> * structure. The service may fetch this and check it. >>> */ >>> List<Object> results = >>> CastUtils.cast((List)msg.get(WSHandlerConstants.RECV_RESULTS)); >>> if (results == null) { >>> results = new Vector<Object>(); >>> msg.put(WSHandlerConstants.RECV_RESULTS, results); >>> } >>> WSHandlerResult rResult = new WSHandlerResult(actor, wsResult); >>> results.add(0, rResult); >>> >>> SOAPBody body = doc.getSOAPBody(); >>> >>> XMLStreamReader reader = StaxUtils.createXMLStreamReader(new >>> DOMSource(body)); >>> // advance just past body >>> int evt = reader.next(); >>> int i = 0; >>> while (reader.hasNext() && i < 1 >>> && (evt != XMLStreamConstants.END_ELEMENT || evt != >>> XMLStreamConstants.START_ELEMENT)) { >>> reader.next(); >>> i++; >>> } >>> msg.setContent(XMLStreamReader.class, reader); >>> String pwType = (String)getProperty(msg, "passwordType"); >>> if ("PasswordDigest".equals(pwType)) { >>> //CXF-2150 - we need to check the UsernameTokens >>> for (WSSecurityEngineResult o : CastUtils.cast(wsResult, >>> WSSecurityEngineResult.class)) { >>> Integer actInt = >>> (Integer)o.get(WSSecurityEngineResult.TAG_ACTION); >>> if (actInt == WSConstants.UT) { >>> WSUsernameTokenPrincipal princ >>> = >>> (WSUsernameTokenPrincipal)o.get(WSSecurityEngineResult.TAG_PRINCIPAL); >>> if (!princ.isPasswordDigest()) { >>> LOG.warning("Non-digest UsernameToken found, but >>> digest required"); >>> throw new >>> WSSecurityException(WSSecurityException.INVALID_SECURITY); >>> } >>> } >>> } >>> } >>> >>> if (!utWithCallbacks) { >>> for (WSSecurityEngineResult o : CastUtils.cast(wsResult, >>> WSSecurityEngineResult.class)) { >>> final Principal p = >>> (Principal)o.get(WSSecurityEngineResult.TAG_PRINCIPAL); >>> if (p instanceof WSUsernameTokenPrincipal) { >>> msg.put(PRINCIPAL_RESULT, p); >>> WSS4JTokenConverter.convertToken(msg, p); >>> SecurityContext sc = msg.get(SecurityContext.class); >>> if (sc == null || sc.getUserPrincipal() == null) { >>> msg.put(SecurityContext.class, >>> createSecurityContext(p)); >>> } >>> break; >>> } >>> } >>> } else { >>> for (WSSecurityEngineResult o : CastUtils.cast(wsResult, >>> WSSecurityEngineResult.class)) { >>> final Principal p = >>> (Principal)o.get(WSSecurityEngineResult.TAG_PRINCIPAL); >>> if (p != null) { >>> msg.put(PRINCIPAL_RESULT, p); >>> if (!utWithCallbacks) { >>> WSS4JTokenConverter.convertToken(msg, p); >>> } >>> SecurityContext sc = msg.get(SecurityContext.class); >>> if (sc == null || sc.getUserPrincipal() == null) { >>> msg.put(SecurityContext.class, >>> createSecurityContext(p)); >>> break; >>> } >>> } >>> } >>> } >>> } >>> >>> -----Ursprüngliche Nachricht----- >>> From: Sergey Beryozkin >>> Sent: Monday, April 04, 2011 1:50 PM >>> To: [email protected] >>> Cc: David Zhang >>> Subject: Re: UsernameToken JBoss Integration >>> >>> Sorry, that one is indeed needed for the encryption itself to succeed. >>> Can you try, for the sake of the test, send unencrypted UTs ? >>> >>> I don't recall if I had the test for the case when the body was also >>> encrypted, would have to check. >>> In meantime, you may want to try the following: >>> >>> - if UT passwords are not encrypted then simply register a CXF >>> interceptor, >>> after WSS4JInInterceptor, extract a WSS4J token and use it to create the >>> Subject and then replace the existing SecurityContext on the message with >>> the new one - if you decide to follow this route then I can provide more >>> info on how existing CXF SecurityContext impls can be reused >>> - if it is not a WSDL-first case then register an >>> AbstractUsernameTokenAuthenticatingInterceptor implementation instead of >>> WSS4InInterceptor but configure it as usual, just do not provide a UT >>> callback >>> >>> Let us know how it goes >>> >>> Sergey >>> >>> On Mon, Apr 4, 2011 at 12:33 PM, David Zhang <[email protected]> >>> wrote: >>> >>> > Hello, >>> > >>> > i still cannot get the AuthenticationInterceptor to work. >>> > >>> > The password callback is needed to retrieve the password for the >>> private >>> > key. Otherwise the server cannot decrypt the SOAP Request. >>> > >>> > However, when the AuthenticationInterceptor is called in the pre-invoke >>> > Phase, the security token is null. >>> > see AbstractSecurityContextInInterceptor.handleMessage() >>> > >>> > Any ideas? >>> > >>> > David >>> > >>> > From: [email protected] >>> > Sent: Friday, April 01, 2011 7:38 AM >>> > To: [email protected] >>> > Subject: Re: UsernameToken JBoss Integration >>> > >>> > Hello Sergey, >>> > >>> > if i remove the password callback, i get another error message: >>> > General security error (WSSecurityEngine: Callback supplied no password >>> > for: myAlias) >>> > >>> > The keystore.properties file contains only the password for the > >>> keystore, >>> > not for the private key inside the keystore. Also i can not find a way >>> > to >>> > create a private key without password by the java keytool. >>> > >>> > Is there another way to provide the password besides the password >>> callback? >>> > Is there maybe a property in the keystore.properties file? I cannot >>> find >>> a >>> > suitable property in this list: >>> > http://cxf.apache.org/docs/ws-securitypolicy.html >>> > >>> > This is the content of the keystore.properties. The ${}-parts are >>> replaced >>> > by maven with actual values: >>> > >>> > >>> > >>> > >>> >>> org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin >>> > org.apache.ws.security.crypto.merlin.keystore.type=jks >>> > >>> >>> org.apache.ws.security.crypto.merlin.keystore.password=${keystore.password} >>> > >>> org.apache.ws.security.crypto.merlin.keystore.alias=${certificate.alias} >>> > org.apache.ws.security.crypto.merlin.file=${keystore.path} >>> > >>> > >>> > >>> > Thank you >>> > David >>> > >>> > -----Ursprüngliche Nachricht----- >>> > From: Sergey Beryozkin >>> > Sent: Thursday, March 31, 2011 10:21 PM >>> > To: [email protected] >>> > Subject: Re: UsernameToken JBoss Integration >>> > >>> > Hi - >>> > >>> > You don't need a password callback in this case. >>> > >>> > Cheers, Sergey >>> > >>> > On Thu, Mar 31, 2011 at 7:42 PM, David Zhang <[email protected]> >>> wrote: >>> > >>> > > Hi Sergey, >>> > > >>> > > thank you very much for taking the time to help me. >>> > > I have set the property you mentioned. Look, this is my >>> configuration: >>> > > >>> > > >>> > > <jaxws:endpoint id="SecureServiceBean" >>> > > >>> > > address="/example-ejb/SecureService" >>> > > >>> > > implementor="com.example.SecureServiceBean"> >>> > > >>> > > <jaxws:invoker> >>> > > >>> > > <bean class="org.jboss.wsf.stack.cxf.InvokerEJB3" /> >>> > > >>> > > </jaxws:invoker> >>> > > >>> > > <jaxws:inInterceptors> >>> > > >>> > > >>> > > <bean class="com.example.AuthenticationInterceptor1"/> >>> > > >>> > > </jaxws:inInterceptors> >>> > > >>> > > <jaxws:properties> >>> > > >>> > > <entry key="ws-security.ut.no-callbacks" value="true" /> >>> > > >>> > > <!--<entry key="ws-security.validate.token" value="false" />--> >>> > > >>> > > <entry key="ws-security.signature.properties" >>> value="keystore.properties" >>> > > /> >>> > > >>> > > <entry key="ws-security.encryption.properties" >>> > value="keystore.properties" >>> > > /> >>> > > >>> > > <entry key="ws-security.callback-handler" >>> > > value="com.example.PasswordCallback" /> >>> > > >>> > > </jaxws:properties> >>> > > >>> > > </jaxws:endpoint> >>> > > >>> > > Where com.example.AuthenticationInterceptor1 extends >>> > > AbstractUsernameTokenInInterceptor. >>> > > This results in: >>> > > 12:01:12,770 ERROR >>> > > >>> > >>> >>> [org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor] >>> > > Security Token is not available on the current message >>> > > >>> > > Thanks >>> > > David >>> > > >>> > > >>> > > -----Ursprüngliche Nachricht----- >>> > > From: Sergey Beryozkin >>> > > Sent: Thursday, March 31, 2011 11:06 AM >>> > > To: [email protected] >>> > > Subject: Re: UsernameToken JBoss Integration >>> > > >>> > > Hi >>> > > >>> > > Please check this section: >>> > > >>> > > >>> > > >>> > >>> >>> http://cxf.apache.org/docs/security.html#Security-WSSecurityUsernameTokenandCustomAuthentication >>> > > >>> > > In 2.3.x you have to set a "ws-security.ut.no-callbacks" property and >>> > this >>> > > will ensure AbstractUserNameTokenInterceptor can be used. >>> > > >>> > > Setting this property results in WSS4JInInterceptor duplicating WSS4J >>> > > specific UT into CXF specific UsernameToken which is what >>> > > AbstractUserNameTokenInterceptor is checking. >>> > > >>> > > Cheers, Sergey >>> > > >>> > > On Thu, Mar 31, 2011 at 8:42 AM, David Zhang <[email protected]> >>> > wrote: >>> > > >>> > > > >>> > > > Hello, >>> > > > >>> > > > >>> > > > >>> > > > i have a web service with symmetric binding and self-signed server >>> > > > certificate. >>> > > > >>> > > > I implemented a password callbackhandler for the password to the >>> > private >>> > > > key of the server. >>> > > > >>> > > > Now i want to add authentication with username token. So i added a >>> > > > supporting token to the ws security policy. >>> > > > >>> > > > >>> > > > >>> > > > To this point everything works fine. The server gets an encrypted >>> > request >>> > > > with a username token. >>> > > > >>> > > > My concern is that i do not want to do the authentication in my >>> > > > application. I want to integrate the username token with JBoss >>> > Security. >>> > > > >>> > > > >>> > > > >>> > > > So i followed these instructions: >>> > > > >>> > > >>> > >>> >>> http://community.jboss.org/wiki/JBossWS-StackCXFUserGuide#Authentication_and_authorization >>> > > > >>> > > > However, it did not work. I used a debugger to check and i saw the >>> > > > authentication interceptor was created when my app was deployed but >>> it >>> > > was >>> > > > never called on a client request. >>> > > > >>> > > > >>> > > > >>> > > > Later i found this: >>> > > > >>> > > >>> > >>> >>> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.3/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/wssec10/server/SimpleSubjectCreatingInterceptor.java >>> > > > >>> > > > I implemented an interceptor following that example. I put a >>> breakpoint >>> > > on >>> > > > the createSubject method. It was never called. >>> > > > >>> > > > >>> > > > >>> > > > Then i followed this example: >>> > > > >>> > > >>> > >>> >>> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.3/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/wssec10/server/SimpleUsernameTokenInterceptor.java >>> > > > >>> > > > At least i know this interceptor was called. But it produced an > > >>> > error >>> > > > before the createSubject method was called. The error says: >>> Security >>> > > Token >>> > > > is not available on the current message >>> > > > >>> > > > >>> > > > >>> > > > But this can not be true. Because then i removed the interceptor >>> > removed >>> > > > the property ws-security.ut.no-callbacks and on the next request my >>> > > password >>> > > > callbackhandler was called with the username i set on the client. >>> > > > >>> > > > >>> > > > >>> > > > Please, can anybody explain me what i am doing wrong? >>> > > > >>> > > > >>> > > > >>> > > > Thanks >>> > > > >>> > > > David >>> >>
