Congrats, Pablo. 1. That's the mistake in Metro trader_client. It should use the endpoint "METRO_BSSTS" rather than the URL to determine the type of BS. 2. Yes, the com.sun.xml.ws.api.security.trust.STSAttributeProvider file is missed. We need to add it according to Jiandong's comment. 3. About the certificate used in the negotiation between trader_client and BSL, it seems BSL.Com would be a better idea. How do you think? If you agree, I'm going to change the implementation in metro to use the cert BSL.com. 4. Can you send me the ActiveSTSAttributeProvider.java file with your changes? I'll change the build script as well to include the deployment of this file.
I plan to do the interoperability between .NET <-> Metro with CBS. Is the .NET code in trunk the newest version you are using? Where can I find the document to set up the .NET implementation and test it? Regards, Ming Jin On Fri, Oct 30, 2009 at 8:33 PM, Pablo Cibraro <pablo.cibr...@tellago.com>wrote: > 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: jiandong....@sun.com [mailto:jiandong....@sun.com] > Sent: Friday, October 30, 2009 4:29 PM > To: stonehenge-dev@incubator.apache.org > 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:skyai...@gmail.com] > > Sent: Thursday, October 29, 2009 7:16 PM > > To: stonehenge-dev@incubator.apache.org > > 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 > > <pablo.cibr...@tellago.com>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:kent.br...@microsoft.com] > >> Sent: Friday, October 23, 2009 8:07 PM > >> To: stonehenge-dev@incubator.apache.org > >> 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:pablo.cibr...@tellago.com] > >> Sent: Friday, October 23, 2009 2:33 PM > >> To: stonehenge-dev@incubator.apache.org > >> 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: jiandong....@sun.com [mailto:jiandong....@sun.com] > >> Sent: Thursday, October 22, 2009 7:00 PM > >> To: stonehenge-dev@incubator.apache.org > >> 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: jiandong....@sun.com [mailto:jiandong....@sun.com] > >>> Sent: Thursday, October 22, 2009 3:04 AM > >>> To: stonehenge-dev@incubator.apache.org > >>> 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. > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > >> > > > > > > > > > -- Ming Jin Consultant Thoughtworks, Inc Twitter: https://twitter.com/mingjin
