Pablo Cibraro wrote:
Thanks Jiandong!!. The latest metro build solved the WS-Trust namespace issue. 
Now I am getting a signature validation error when .NET tries to validate the 
SAML token signature (The token included in the ActAs element). What I noticed 
is that Metro is sending some line break characters in the SignatureValue and 
X500Certificate elements (see below). Do you think that could be an issue ?. 
(WCF is not adding line breaks)
It should be fine. It allowed to add line break in every 76 characters in Base 64. We also have the line breaks for the Metro ActiveSTS issued Assertions.
It works with .Net service as you have tested.

Thanks!

Jiandong
<wst14:ActAs xmlns:wst14="http://docs.oasis-open.org/ws-sx/ws-trust/200802";>
                  <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" 
AssertionID="scd54f637d0b74ed3f4b9dfe30446f4a93454cbd501" IssueInstant="2009-11-02T19:55:47Z" Issuer="Fedidp" 
MajorVersion="1" MinorVersion="1">
                    <saml:Conditions NotBefore="2009-11-02T19:45:47Z" 
NotOnOrAfter="2009-11-02T20:05:47Z">
                      <saml:AudienceRestrictionCondition>
                        <saml:Audience>Fedsp</saml:Audience>
                      </saml:AudienceRestrictionCondition>
                    </saml:Conditions>
                    <saml:AuthenticationStatement 
AuthenticationInstant="2009-11-02T19:55:47Z" 
AuthenticationMethod="urn:com:sun:identity:DataStore">
                      <saml:Subject>
                        <saml:NameIdentifier 
Format="http://schemas.xmlsoap.org/claims/UPN";>uid:0...@stonehenge.com</saml:NameIdentifier>
                      </saml:Subject>
                    </saml:AuthenticationStatement>
                    <ns9:Signature 
xmlns:ns9="http://www.w3.org/2000/09/xmldsig#";>
                      <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#";>
                        <CanonicalizationMethod 
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";></CanonicalizationMethod>
                        <SignatureMethod 
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1";></SignatureMethod>
                        <Reference 
URI="#scd54f637d0b74ed3f4b9dfe30446f4a93454cbd501">
                          <Transforms>
                            <Transform 
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature";></Transform>
                            <Transform 
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";></Transform>
                          </Transforms>
                          <DigestMethod 
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1";></DigestMethod>
                          
<DigestValue>Gxbyd0OyoKbGbFEyV6fQaFKTi3M=</DigestValue>
                        </Reference>
                      </SignedInfo>
                      <SignatureValue xmlns="http://www.w3.org/2000/09/xmldsig#";>  
EZYvSXFKntInKY4SS9ND6IdRozlNlxEZ3HFTr3pV8IYLg1NX+YoPufIx7etQW3dkf54pjaTLHNCy  
eXIJoftvwJIijpQK48Uypn5BEnmbQDnmlxdpS56R+5CAIz1vAJYuZ0jvsKVd1IKd3z6GmdjZ3LcK  nXsbq4OzXWKICpkL9+M=  
</SignatureValue>
                      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#";>
                        <X509Data>
                          <X509Certificate>  
MIICQDCCAakCBEeNB0swDQYJKoZIhvcNAQEEBQAwZzELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh  
bGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMQwwCgYDVQQKEwNTdW4xEDAOBgNVBAsTB09w  
ZW5TU08xDTALBgNVBAMTBHRlc3QwHhcNMDgwMTE1MTkxOTM5WhcNMTgwMTEyMTkxOTM5WjBnMQsw  
CQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExDDAK  
BgNVBAoTA1N1bjEQMA4GA1UECxMHT3BlblNTTzENMAsGA1UEAxMEdGVzdDCBnzANBgkqhkiG9w0B  
AQEFAAOBjQAwgYkCgYEArSQc/U75GB2AtKhbGS5piiLkmJzqEsp64rDxbMJ+xDrye0EN/q1U5Of+  
RkDsaN/igkAvV1cuXEgTL6RlafFPcUX7QxDhZBhsYF9pbwtMzi4A4su9hnxIhURebGEmxKW9qJNY  
Js0Vo5+IgjxuEWnjnnVgHTs1+mq5QYTA7E6ZyL8CAwEAATANBgkqhkiG9w0BAQQFAAOBgQB3Pw/U  
QzPKTPTYi9upbFXlrAKMwtFf2OW4yvGWWvlcwcNSZJmTJ8ARvVYOMEVNbsT4OFcfu2/PeYoAdiDA  
cGy/F2Zuj8XJJpuQRSE6PtQqBuDEHjjmOQJ0rV/r8mO1ZCtHRhpZ5zYRjhRC9eCbjx9VrFax0JDC  
/FfwWigmrW0Y0Q==  </X509Certificate>
                        </X509Data>
                      </KeyInfo>
                    </ns9:Signature>
</saml:Assertion>
                </wst14:ActAs>

Thanks
Pablo.

-----Original Message-----
From: jiandong....@sun.com [mailto:jiandong....@sun.com] Sent: Monday, November 02, 2009 4:04 PM
To: stonehenge-dev@incubator.apache.org
Subject: Re: Third interop test between Metro and .NET

Pablo,

See inline ...

Pablo Cibraro wrote:
I finally could make some progress in the interop tests with the Active STS. I 
used the following configuration,


1.       Trader client application (Metro)

2.       Passive STS (Metro)

3.       Active STS (.NET)

4.       Business Service (Metro)

Unfortunately, I found a blocking issue that I think it is hard to fix (at 
least in WCF). The namespace used by metro for the ActAs element is different 
from the namespace used by WCF.

Metro,

<wst:ActAs xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512";>

.NET (WCF)

<tr:ActAs xmlns:tr="http://docs.oasis-open.org/ws-sx/ws-trust/200802";>
There was some ambiguity for the namespace to be used with ActAs. The WS-Trust 1.4 spec and schema specified differently. This issue has been clarified recently in the ws-sx TC. So that we have updated Metro to use "http://docs.oasis-open.org/ws-sx/ws-trust/200802";.

Can you try with latest Metro nightly?
 
https://metro.dev.java.net/servlets/ProjectDocumentList?expandFolder=7638&folderID=10314

It is more close to the one to be released.

I will get back to the other issues below shortly.


Thanks!

Jiandong



Besides that issue with the WS-Trust message, these are my findings for this 
scenario,


1.       The active STS in metro is using an username token for authenticating 
the client application (trader web client). .NET is using a client certificate 
for that purpose (BSL.Com), and I think it is the correct mechanism. I 
basically changed the .NET Active STS and trader client implementation to use 
username tokens.

2.       The wsit-client.xml for the trader client application in metro looks 
as follow,

               <tc:PreconfiguredSTS 
xmlns:tc="http://schemas.sun.com/ws/2006/05/trust/client";
                                     
endpoint=http://localhost:9001/tradeactivests (.NET)
                                     
wsdlLocation=http://apps.stonehenge.com:1316/active_sts/ActiveSTS?wsdl (WSDL in 
METRO)
                                     serviceName="SecurityTokenService"
                                     portName="ISecurityTokenService_Port"
                                     namespace="http://tempuri.org/"; 
shareToken="true">
                </tc:PreconfiguredSTS>

                I could not make it work against the .NET Active STS Wsdl. For 
some reasons, all the requests with that WSDL are not protected with 
WS-Security. I updated all the bindings and ports in the .NET to use 
ISecurityTokenService and http://tempuri.org as namespace, but that does not 
work.


3.       Metro was using derived keys and basic 128 as algorithm suite. WCF was 
throwing a weird parsing error exceptions for the derived keys (this option was 
enabled in the WCF bindings too), so I disable that feature in metro and .NET.

"Cannot read the token from the 'DerivedKeyToken' element with the 
'http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512' namespace for 
BinarySecretSecurityToken, with a '' ValueType. If this element is expected to be valid, 
ensure that security is configured to consume tokens with the name, namespace and value 
type specified."

Regards,
Pablo.





Reply via email to