Hi, It's a pity you can't update to use CXF 3.1.x - the next release has support for issuing JWT Tokens in the STS.
> 1. Is there any way to use openSAML 2 & 3 at the same time? (So that I can directly use the latest CXF & wss4j, I tried but failed..) I don't think so. > 2. Is there any plan to release a new patch version based on 1.6.X containing the fix the WSS-519 issue? No, 1.6.x is no longer supported. > 3. Based on wss4j 1.6.19, how can I configure the CXF spring files to use a customized Processor? is it a must to configure an Interceptor? Any guidelines would be helpful to me. You should be able to follow the same approach. The same processors are used for WS-SecurityPolicy and for the non-WS-SecurityPolicy case. You could create a custom CXF interceptor that runs before the WS-Security interceptors to set up WSSConfig accordingly. > 4. Like the last comment from Viliam Repan in WSS-519, seems in some case, the "EncryptedKeyProcessor" is created > on demand, will the solution in 3 failed in such cases? Hmm that looks like a separate bug. I will look into that for WSS4J 2.x. If it still doesn't work for you, you will have to just create a local patched version of WSS4J 1.6.x containing the fix for WSS-519. Colm. On Wed, Mar 23, 2016 at 1:15 PM, 柳幸楠 <wwwc...@gmail.com> wrote: > Hello, > > Currently I'm working on creating an STS using CXF 2.7.18 and wss4j > 1.6.19. What I want is the STS could be able to receive a SAML token and > send a JwtToken back as a RSTR. > > I've succeeded create a JwtTokenProvider and make the flow work when I use > SAML 1.0/1.1 from MicroSoft ADFS, however, it does not work when using SAML > 2. Then I found a defect https://issues.apache.org/jira/browse/WSS-519 talking > about this issue. And SAML 2 works fine when I upgrade CXF2.7.18 to latest > CXF3.1.4, which is using wss4j-ws-security-common 2.1.4. > > However I *cannot *upgrade because I'm using Spring Security SAML to > achive another SAML flow, and it is using OpenSAML2.6 which will cause > class collision with OpenSAML 3( which the latest wss4j is using). > > As Colm mentioned in that issue, the fix was not merged into the 1.6.X > branch, the users would better extend the processor and set in WSSConfig. > However, in my STS code, I did not config any InInterceptor, it seems this > interceptor is automatially created based on the WS-Policy. > > So I want to know: > 1. Is there any way to use openSAML 2 & 3 at the same time? (So that I > can directly use the latest CXF & wss4j, I tried but failed..) > 2. Is there any plan to release a new patch version based on 1.6.X > containing the fix the WSS-519 issue? > 3. Based on wss4j 1.6.19, how can I configure the CXF spring files to use > a customized Processor? is it a must to configure an Interceptor? Any > guidelines would be helpful to me. > 4. Like the last comment from Viliam Repan in WSS-519, seems in some case, > the "EncryptedKeyProcessor" is created on demand, will the solution in 3 > failed in such cases? > > I'm new to WS-Trust, actually new to SOAP based WebService... Hope I have > expressed myself and you could have time to answer the questions. > > Thanks in advance! > > Here's the sample SAML 2 assertion: > > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> > <soap:Header> > <wsse:Security soap:mustUnderstand="1" > xmlns:wsse=" > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd > " > xmlns:wsu=" > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";><EncryptedAssertion > xmlns="urn:oasis:names:tc:SAML:2.0:assertion"><xenc:EncryptedData Type=" > http://www.w3.org/2001/04/xmlenc#Element"; xmlns:xenc=" > http://www.w3.org/2001/04/xmlenc#";> > <xenc:EncryptionMethod Algorithm=" > http://www.w3.org/2001/04/xmlenc#aes256-cbc"/> > <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#";> > <e:EncryptedKey xmlns:e=" > http://www.w3.org/2001/04/xmlenc#";> > <e:EncryptionMethod Algorithm=" > http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p";> > <DigestMethod Algorithm=" > http://www.w3.org/2000/09/xmldsig#sha1"/> > </e:EncryptionMethod> > <KeyInfo> > <ds:X509Data xmlns:ds=" > http://www.w3.org/2000/09/xmldsig#";> > <ds:X509IssuerSerial> > <ds:X509IssuerName>CN=apollo, > OU=R&D, O=RM5 Software Oy, L=Helsinki, S=Uusimaa, > C=FI</ds:X509IssuerName> > > <ds:X509SerialNumber>1357039681</ds:X509SerialNumber> > </ds:X509IssuerSerial> > </ds:X509Data> > </KeyInfo> > <e:CipherData> > <e:CipherValue>XXXXXX</e:CipherValue> > </e:CipherData> > </e:EncryptedKey> > </KeyInfo> > <xenc:CipherData> > <xenc:CipherValue>XXX</xenc:CipherValue> > </xenc:CipherData> > </xenc:EncryptedData> > </EncryptedAssertion> > </wsse:Security> > </soap:Header> > <soap:Body> > <wst:RequestSecurityToken > xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512";> > <wst:TokenType>urn:ietf:params:oauth:token-type:jwt</wst:TokenType> > <wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer > </wst:KeyType> > <wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue > </wst:RequestType> > <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";> > <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing";> > <wsa:Address> > https://localhost:8081/doubleit/services/doubleittransportsaml1claims > </wsa:Address> > </wsa:EndpointReference> > </wsp:AppliesTo> > </wst:RequestSecurityToken> > </soap:Body> > </soap:Envelope> > > -- > *Best Regards!* > > Liu Xingnan > 柳幸楠 > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
