Cool, thanks. I have this scenario working too. I had to change something in the ActiveSTSAttributeProvider class, as now, WIF expects SAML attributes as part of the http://schemas.xmlsoap.org/ws/2009/09/identity/claims/actor attribute. This is what WIF RTM expects,
<Actor> <saml:Attribute AttributeName="name" AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims"; xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"> <saml:AttributeValue>uid:0</saml:AttributeValue> </saml:Attribute> <saml:Attribute AttributeName="authenticationinstant" AttributeNamespace="http://schemas.microsoft.com/ws/2008/06/identity/claims"; xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"> <saml:AttributeValue a:type="tn:dateTime" xmlns:tn="http://www.w3.org/2001/XMLSchema"; xmlns:a="http://www.w3.org/2001/XMLSchema-instance";>2009-12-18T17:19:04.852Z</saml:AttributeValue></saml:Attribute><saml:Attribute AttributeName="authenticationmethod" AttributeNamespace="http://schemas.microsoft.com/ws/2008/06/identity/claims"; xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"><saml:AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</saml:AttributeValue> </saml:Attribute></Actor> Basically, an element <Actor> with some saml attributes on it. Thanks Pablo. -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Sunday, December 13, 2009 4:41 AM To: [email protected] Subject: Re: First interop test between Metro and .NET Add extension=true to <wsimport debug="${debug}" verbose="${verbose}" keep="${keep}" destdir="${build.classes.home}" wsdl="${business.service.wsdl}"> Thanks! Jiandong Pablo Cibraro wrote: > Hi Jiandong, > > I tried to update the business service endpoint to use Soap 1.2 following the > steps you mentioned below. I am getting the following compilation error after > running the build process, > > build: > [wsimport] Consider using <depends>/<produces> so that wsimport won't do > unnece > ssary compilation > [wsimport] parsing WSDL... > [wsimport] > [wsimport] > [wsimport] [WARNING] Ignoring SOAP port "BasicHttpBinding_ITradeServices": > it u > ses non-standard SOAP 1.2 binding. > [wsimport] You must specify the "-extension" option to use this binding. > [wsimport] line 489 of > file:/C:/src/metro/etc/business_service/TradeServiceWs > as.wsdl > [wsimport] > [wsimport] [WARNING] Ignoring SOAP port "CustomBinding_ITradeServices": it > uses > non-standard SOAP 1.2 binding. > [wsimport] You must specify the "-extension" option to use this binding. > [wsimport] line 492 of > file:/C:/src/metro/etc/business_service/TradeServiceWs > as.wsdl > [wsimport] > [wsimport] [WARNING] Service "TradeServiceWsas" does not contain any usable > por > ts. try running wsimport with -extension switch. > [wsimport] line 488 of > file:/C:/src/metro/etc/business_service/TradeServiceWs > as.wsdl > > The ant script is already using the -extension switch. For some reason, the > proxies are not being generated. Do you have any idea about what could be > wrong ? > > Thanks > Pablo. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Sunday, November 01, 2009 1:33 AM > To: [email protected] > Subject: Re: First interop test between Metro and .NET > > Any plan to test with Trade client and ActiveSTS from different Vendors. > This is the case never tested before with ActAs in RST. So it is > interesting to see if it works. > > See inline ... > > Pablo Cibraro wrote: > >> These are my findings, >> >> - Metro is using SOAP 1.1 >> > It is easy to change to SOAP 1.2: in > stonehengeWithCBS\business_service\etc\sun-jaxws.xml, add > binding="http://www.w3.org/2003/05/soap/bindings/HTTP/"; > to both endpoints; then change all soap: to soap12: in > TradeServiceWsas.wsdl. > > >> with WS-Addressing 1.0, so I changed all the WCF configuration in .NET to >> use those protocol versions >> >> > WS-Addressing 1.0 with namespace "http://www.w3.org/2005/08/addressing"; is > the latest version of ws-addressing. Which version were you using for .Net? > > Thanks! > > Jiandong > > > >> - 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. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> > >
