Pablo,
Changing the .NET config to the old bindings to interop with Metro as it is now configured is probably the right first step so we can test the CBD side of things.
We would ultimately like to upgrade everything to use the more modern versions
of the specs. Not sure if we should get through all the tests with the old
bindings and then go back and upgrade everything one at a time, or if we should
go ahead and upgrade everything. Also, should we keep old and new around as
different endpoint configurations, or just upgrade and forget about the old
versions?
Interested in others' thoughts.
Kent
-----Original Message-----
From: Pablo Cibraro [mailto:[email protected]]
Sent: Friday, October 30, 2009 1:34 PM
To: [email protected]
Subject: RE: First interop test between Metro and .NET
Thanks Jiandong for providing this information!!. I have the first scenario
working,
Config Service -> Metro
Business Service -> .NET
Active STS -> Metro
Passive STS -> Metro
Trader client -> Metro
These are my findings,
- Metro is using SOAP 1.1 with WS-Addressing 1.0, so I changed all the WCF
configuration in .NET to use those protocol versions
- The Metro Active is signing/encrypting the SAML token with the certificate
OPS.Com, and .NET was expecting BSL.Com (According to the specification, the
ActiveSTS is run in the same domain as the business service, so BSL.Com looks
like a better option). I changed the .NET implementation to use OPS.Com, and
that fixed the problem.
- There is bug in the metro compilation process, the com.sun.xml.ws.api.security.trust.STSAttributeProvider file was missing, and therefore it was not included in the active sts war file. I need this to apply some transformations in the SAML Attributes (The Attribute provider that comes out of the box generates an ActAs attribute without namespace so WCF is complaining about that). I created this file to use the ActiveSTSAttributeProvider implementation.
- I changed the ActiveSTSAttributeProvider implementation to provide a namespace for the ActAs attribute
I can commit these two changes as patch for the Metro implementation if you want.
My next step is to do the opposite, run the Metro Business Service and the rest
of the components in .NET
Regards,
Pablo.
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Friday, October 30, 2009 4:29 PM
To: [email protected]
Subject: Re: First interop test between Metro and .NET
Pablo Cibraro wrote:
Hi Ming,
1. I think we should create a new endpoint for the business service that expects SAML tokens. In the current version we only have "DOTNET_BS" and "METRO_BS" (I noticed you created a new endpoint METRO_BSSTS, but the trader client application still uses the rule of the URL prefix). The .NET implementation does not support the basic profile anymore for the business service as it does not make sense anymore if we are planning to use claim based security in that service.
That is the general practice to have different endpoints for different
authentication setting.
2. Ok, I changed that class but it is not being used at all by the Active STS.
Is that class automatically loaded (I could not find any configuration that
references that class) ?. If it is, there is a problem there because it is not
being loaded. Any clue about what need to be changed ?
It should be loaded using the standard java service finding mechanism:
in the active_sts.war created, there should have an file
WEB-INF\classes\META_INF\services\com.sun.xml.ws.api.security.trust.STSAttributeProvider.
Here "com.sun.xml.ws.api.security.trust.STSAttributeProvider" is the file name,
the content of the file is the classpath of your implementing class of the interface, e.g.
org.apache.stonehenge.stockstrade.sts.ActiveSTSAttributeProvider"
I was planning to use something like "http://sun"; as the namespace.
Microsoft Geneva is using
http://schemas.microsoft.com/ws/2008/06/identity/claims/actingas
With latest build we should all have changed to
"http://schemas.xmlsoap.org/ws/2009/09/identity/claims/actor"; (actor is the
attribute name, http://schemas.xmlsoap.org/ws/2009/09/identity/claims
<http://schemas.xmlsoap.org/ws/2009/09/identity/claims/actor>
namespace) to ensure we have the same one to repent the identity of the
requester.
Regards,
Jiandong
Regards,
Pablo.
-----Original Message-----
From: Ming Jin [mailto:[email protected]]
Sent: Thursday, October 29, 2009 7:16 PM
To: [email protected]
Subject: Re: First interop test between Metro and .NET
Hi Pablo,
1. We assumed the address of SEI consuming Active STS be ended up with
"STS", you need to change to the URL with "STS" suffix. Meanwhile, as
now we have Active STS implementations of Metro and WCF, I think we
need to discuss the naming convention of these URLs. What's your opinion?
2. Yes, the ActiveSTSAttributeProvider is the class generating the
attributes. What namespace are you going to use?
Best Regards,
Ming Jin
On Thu, Oct 29, 2009 at 10:02 PM, Pablo Cibraro
<[email protected]>wrote:
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.
