I finally found the problem. The trader_client application in metro is only
negotiating a SAML token when the business service endpoint url ends up with
"STS", so I changed the endpoint in .NET to be
"http://localhost:9000/businessserviceSTS";. After that, I started receiving
messages with the SAML token, but I got some interop errors that I could fix (I
will send the list later). Now, I am getting an error in one of the attributes
that the ActiveSTS in metro is adding to the token
<saml:Attribute AttributeName="ActAs" AttributeNamespace="">
<saml:AttributeValue>
<!--Removed-->
</saml:AttributeValue>
</saml:Attribute>
The attributeNamespace is empty, and WCF is complaining about that. Could you
confirm that the class in metro that is generating the attributes is
ActiveSTSAttributeProvider ? So I can change it on my side and see if that
fixes the issue.
Thanks
Pablo.
-----Original Message-----
From: Kent Brown [mailto:[email protected]]
Sent: Friday, October 23, 2009 8:07 PM
To: [email protected]
Subject: RE: First interop test between Metro and .NET
I don't see the WSDL. Does the listserv allow attachments? Maybe attach to a
JIRA ticket.
-----Original Message-----
From: Pablo Cibraro [mailto:[email protected]]
Sent: Friday, October 23, 2009 2:33 PM
To: [email protected]
Subject: RE: First interop test between Metro and .NET
Sure. I attached the business service WSDL. Let me know if that helps.
Thanks
Pablo.
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Thursday, October 22, 2009 7:00 PM
To: [email protected]
Subject: Re: First interop test between Metro and .NET
Pablo Cibraro wrote:
> Hi Jiandong,
>
> "To ensure interoperability in this stage, we should all use issued
> token with a symmetric proof key as an EndorsingSupportingToken.
> The issued token can be encrypted by the Active STS with the service
> certificate and of course signed by the STS."
>
> I am sorry, that is what I meant when I said a SAML token as client
> credential :). BSL.Com is the certificate we used in the Active STS
> for encrypting
Ok
> and signing the issued token
the issued token should be signed with the issuer's private key, i.e the
private key of the Active STS.
Can you send me the .Net Business Service wsdl with security policy in it to
make sure we are in the same page?
> . According to some tests I ran yesterday, I noticed Metro is using OPS.Com
> for that purpose.
>
That should be a mistake.
Thanks!
Jiandong
> Thanks
> Pablo.
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Thursday, October 22, 2009 3:04 AM
> To: [email protected]
> Subject: Re: First interop test between Metro and .NET
>
> About the security setting for the BS service and interoperability:
>
>
>> .NET is expecting a message with the following requirements,
>>
>>
>> 1. WS Security 1.1 (We need to agree on this)
>>
>> 2. A SAML token as client credential signed and encrypted with the
>> BSL.Com certificate (And the userID profile as a claim in that token)
>>
>>
> In terms of security policy, this means you have a SymmetricBinding
> with
> X509 cert as protection token and an (probably bearer?) issued token
> as a SignedEncryptedSupportingToken.
>
> It is set up differently for Metro based BS service: SymmetricBinding
> with X509 cert as protection token and an keyed ssued token as an
> EndorsingSupportingToken.
>
> There are 2 issues here:
>
> 1. The BS web service client may be created against a local copy of
> the service wsdl. In this case we have a mismatch of security setting
> between the BS client and the BS server.
> 2. Even if the BS client is created from the live wsdl of the BS
> service, we actually have never tested the interoperability with
> issued token as other than an EndorsingSupportingTken (see the
> plugfest scenarios at http://mssoapinterop.org/ilab/). This is because
> of the use/lack of use of str-transform for signing SAML assertion in
> a message in different platforms. It is being addressed but may take
> time.
>
> To ensure interoperability in this stage, we should all use issued
> token with a symmetric proof key as an EndorsingSupportingToken.
> The issued token can be encrypted by the Active STS with the service
> certificate and of course signed by the STS.
>
> Thanks!
>
> Jiandong
>
>> Am I missing something, do I need to configure something else in the Metro
>> Trader Client application to secure the messages and use a SAML token ?.
>>
>> Thanks
>> Pablo.
>>
>>
>>
>>
>
>
>
>
