About SAML 2 handling in version wss4j 1.6.19

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

About SAML 2 handling in version wss4j 1.6.19

柳幸楠
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: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&amp;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
<wst:TokenType>urn:ietf:params:oauth:token-type:jwt</wst:TokenType>
<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
</wsa:EndpointReference>
</wsp:AppliesTo>
</wst:RequestSecurityToken>
</soap:Body>
</soap:Envelope>

--
Best Regards!

Liu Xingnan
柳幸楠
Reply | Threaded
Open this post in threaded view
|

Re: About SAML 2 handling in version wss4j 1.6.19

Colm O hEigeartaigh-2
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, 柳幸楠 <[hidden email]> 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: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&amp;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
<wst:TokenType>urn:ietf:params:oauth:token-type:jwt</wst:TokenType>
<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
</wsa:EndpointReference>
</wsp:AppliesTo>
</wst:RequestSecurityToken>
</soap:Body>
</soap:Envelope>

--
Best Regards!

Liu Xingnan
柳幸楠



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: About SAML 2 handling in version wss4j 1.6.19

柳幸楠
Hi Colm,

Thank you very much for the information.

Update my solution on handling SAML 2 token from ADFS:

1. version
     CXF version: 2.7.18
     WSS4J version: 1.6.19
2. create a "ProcessorInjectorInterceptor" to set the patched processor.
     config = WSSConfig.getNewInstance();
     config.setProcessor(WSSecurityEngine.ENCRYPTED_DATA, PatchedEncryptedDataProcessor.class);
3. use your solution in the former mail and https://issues.apache.org/jira/browse/WSS-519 to patch “EncryptedDataProcessor” and "EncryptedKeyProcessor". 

Hope this could help other ones who may have the same problem.


2016-03-24 17:34 GMT+08:00 Colm O hEigeartaigh <[hidden email]>:
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, 柳幸楠 <[hidden email]> 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: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&amp;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
<wst:TokenType>urn:ietf:params:oauth:token-type:jwt</wst:TokenType>
<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
</wsa:EndpointReference>
</wsp:AppliesTo>
</wst:RequestSecurityToken>
</soap:Body>
</soap:Envelope>

--
Best Regards!

Liu Xingnan
柳幸楠



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com



--
Best Regards!

Liu Xingnan
柳幸楠