Jiandong, Yes, it is only using the assertion when the business service is invoked through the endpoint /business_service/TradeServiceWsasSTS. (You usually invoke the business service by browsing the home or account page after you were authenticated in the idp). That filter is storing the assertion in a cookie, so if that string replacement is not made, the assertion gets truncated. The cookie with the assertion is used just before invoking the business service. Make sure you are using that endpoint for the business service
Thanks Pablo. -----Original Message----- From: jiandong....@sun.com [mailto:jiandong....@sun.com] Sent: Tuesday, November 10, 2009 5:29 AM To: stonehenge-dev@incubator.apache.org Subject: Re: Third interop test between Metro and .NET Pablo, I don't see the use of assertion = assertion.replaceAll("\\\\\"", "'").replaceAll("\"", "'"); After I removed it from the STSFilter, it still worked fine for me. What is the exception in your test after you removed it? Thanks! Jiandong Pablo Cibraro wrote: > Ming, > > How hard would be to change the trader client application to store the > assertion in some other place different from a cookie (Session maybe ??) ? > The string replacement + code that save the saml assertion into a cookie are > corrupting the SAML signature somehow, so .NET is complaining about that. > This is the only change we need to make this scenario work. > > Thanks > Pablo. > > -----Original Message----- > From: Pablo Cibraro [mailto:pablo.cibr...@tellago.com] > Sent: Thursday, November 05, 2009 2:05 PM > To: stonehenge-dev@incubator.apache.org > Subject: RE: Third interop test between Metro and .NET > > Unfortunately, it did not work. This line is also breaking the signature, > > assertion = assertion.replaceAll("\\\\\"", "'").replaceAll("\"", "'"); > > It is basically replacing the quotes by a single quote in the SAML token xml. > I tried to remove that line, but the application throws an exception in some > other place. That's definitely the source of the problem because I saved the > SAML assertion in a text file before doing the string replacement, > > String assertion = ssoToken.getProperty("Assertion"); > //I saved the assertion variable here.... > > The saml assertion in the file passes the signature validation that Geneva is > making. > > I am now trying to find out a workaround for passing the original saml > assertion without applying the string replacements to the active STS. > > Regards, > Pablo. > > -----Original Message----- > From: jiandong....@sun.com [mailto:jiandong....@sun.com] > Sent: Wednesday, November 04, 2009 5:30 PM > To: stonehenge-dev@incubator.apache.org > Subject: Re: Third interop test between Metro and .NET > > Pablo, > > Great effort!! > > See inline ... > > Pablo Cibraro wrote: > >> Ok guys, I could find the source of the signature issue in the SAML token, >> it took me some time to figure out what was going on. The trader client >> implementation in metro is modifying the SAML token somewhere, and that's >> corrupting the signature. I think it is happening in the STSFilter.java >> class, in this line, >> >> String assertion = ssoToken.getProperty("Assertion"); >> assertion = assertion.replaceAll("\\\\\"", "'").replaceAll("\"", >> "'").replaceAll(">\\s+?<", "><"); >> >> > Removing the spaces between the sub-elements with "replaceAll(">\\s+?<", > "><")" would break the signature. Could you remove it to see if it works? > > Thanks! > > Jiandong > >> I could not debug anything, so I am not completely sure the problem is in >> that place. On my side, what I did was to catch all the network traffic >> using Fiddler, and I got all the WS-Federation passive messages. In one of >> them, I got the RSTR message with the SAML token that the passive STS was >> generating. >> >> <input type="hidden" name="wresult" >> value="<wst:RequestSecurityTokenResponse >> xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"><wst:RequestedSecurityToken><saml:Assertion >> xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" >> MajorVersion="1" MinorVersion="1" >> AssertionID="s2675032b172b413d3d1a4cd29bd171f535775db101" >> Issuer="Fedidp" IssueInstant="2009-11-04T17:10:59Z" >> >
<saml:Conditions NotBefore="2009-11-04T17:00:59Z" >> NotOnOrAfter="2009-11-04T17:20:59Z" >> >
<saml:AudienceRestrictionCondition>
<saml:Audience>Fedsp</saml:Audience>
</saml:AudienceRestrictionCondition>
</saml:Conditions>
<saml:AuthenticationStatement >> AuthenticationMethod="urn:com:sun:identity:DataStore" >> AuthenticationInstant="2009-11-04T17:10:59Z">
<saml:Subject>
<saml:NameIdentifier >> >> Format="http://schemas.xmlsoap.org/claims/UPN">uid:0...@stonehenge.com</saml:NameIdentifier>
</saml:Subject>
</saml:AuthenticationStatement>
<Signature >> >> xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod >> >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference >> >> URI="#s2675032b172b413d3d1a4cd29bd171f535775db101">
<Transforms>
<Transform >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<Transform >> >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>uiyuOCn7sEO2zUiR6+84uw7smC8=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
B+GMbSKwbmTX0+ZzouliUGmqlWYKdSLu8sb6eQeF7bvQymQjrRy5kvNG9gxxNWlD8t+0BKMgb70s
dl1oHxhrebz3tVLcg3RE/30FLrhtI5R8QpIbeiXDfpP6v9oTp6Tyvkj0TR3D136QJwElk56ya20y
n8s9C5ktTpkXK6Fgix0=
</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>
MIIB8DCCAVmgAwIBAgIQblTMtVPsaJNFRKtH3ePDszANBgkqhkiG9w0BAQQFADASMRAwDgYDVQQD
EwdCU0wuQ29tMB4XDTA4MDUyMTA0NDgxNVoXDTM5MTIzMTIzNTk1OVowEjEQMA4GA1UEAxMHQlNM
LkNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArai/gNTS+dU4GvMSB5VfkFL1e5ielRhg
tnWJ70Xpl51ABksTFkpRNcLDo56sdXtnk3sKEGWe2QeQ1uoBo0bN7aQTsHCNjuT5K/YD4/y2j+oe
RESrz905mJ4owW08MnxkhUzpa6+iPGq0l3TdZaG0GHuuky6wEWe3Chc0hdwCdv0CAwEAAaNHMEUw
QwYDVR0BBDwwOoAQcMZu+2G/jyh39/5QO/5nIKEUMBIxEDAOBgNVBAMTB0JTTC5Db22CEG5UzLVT
7GiTRUSrR93jw7MwDQYJKoZIhvcNAQEEBQADgYEApc0gYQl50mS2RklQnoCpRX/wEfdwhNIQXcMj
/6eqcf9Ul6623Ge2jDNMgQesLAK+rp+kKFqgL6F4odrqxY1u00QvUPQi9LLjWBUi1xAiNnd9lBwm
D7z4ITsxhU40/ON+GVIHJ1CbeWvTwE5TaFyCP6uRSDX1Ojv+tovYt6X5Y4w=
</X509Certificate>
</X509Data>
</KeyInfo>
</Signature></saml:Assertion>
</wst:RequestedSecurityToken><wsp:AppliesTo >> >> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"><wsa:EndpointReference >> >> xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"><wsa:Address>Fedsp</wsa:Address></wsa:EndpointReference></wsp:AppliesTo></wst:RequestSecurityTokenResponse>";> >> >> As you can see, the RSTR was encoded. What I did next was to decode that >> message using some helper classes in .NET, and load the SAML token with the >> Geneva Framework. In this case, the signature was successfully validated by >> Geneva. >> >> To conclude, the issue is in the metro code. Any idea about where I should >> take a look to fix this issue ?. >> >> BTW: I can also include the keystore with the BSL certificate as a patch in >> Jira if you think is convenient (the process of generating this keystore is >> a bit painful for someone that is not familiar with Java). >> >> Thanks >> Pablo. >> >> -----Original Message----- >> From: Ming Jin [mailto:skyai...@gmail.com] >> Sent: Tuesday, November 03, 2009 10:35 PM >> To: stonehenge-dev@incubator.apache.org >> Subject: Re: Third interop test between Metro and .NET >> >> The test certificate is the default certificate used in OpenSSO for the >> signature and encryption. You can follow the link Jiandong gave to change >> the settings in IDP and re-generate the idp&sp configuration file. >> >> In my mind, you need to use openssl to convert the .pfx file into .keystore >> file(with PrimaryKey entry). Moreover, you need to install extra >> ssoAdminTool for OpenSSO to get the command line utility: >> http://docs.sun.com/app/docs/doc/820-3320/gerlv?a=view >> >> Regards, >> Ming Jin >> On Tue, Nov 3, 2009 at 11:01 PM, Jiandong Guo <jiandong....@sun.com> wrote: >> >> >> >>> Pablo Cibraro wrote: >>> >>> >>> >>>> As far as I could see, the IDP (passive STS) is using a test certificate >>>> (CN=test) for signing the SAML token (Not sure if that can be the issue). I >>>> tried to change the certificate to the use BSL.Com (The certificate that >>>> the >>>> passive STS in .NET is using). I basically changed the certicate in the >>>> Fedidp.xml file, and I tried to deploy the file again in the opensso >>>> instance running in the idp. However, I am getting a permission error or >>>> something like that. >>>> >>>> >>>> >>>> >>> The exception below is not harmful. You need to put the cert in the >>> keystore used and have .storepass and .keypass file with the encrypted key >>> and store password: >>> http://docs.sun.com/app/docs/doc/820-3885/ghuxt?a=view >>> >>> Maybe you can first try to put the "test" cert into the your key store for >>> STS to see if the signature can be verified. >>> The base64 encoding of the cert is in the SAML assertion. >>> >>> Thanks! >>> >>> Jiandong >>> >>> >>> >>> [#|2009-11-03T16:01:36.778-0400|WARNING|sun-appserver9.1|com.sun.xml.ws.wspolicy.com.sun.xml.ws.api.policy.ModelTranslator|_ThreadID=10;_ThreadName=main;_RequestID=d6f93987-e8d6-485b-aa77-8996d6ac1b7a;|WSM1007: >>> >>> >>>> Failed to create a ModelTranslator instance. >>>> >>>> com.sun.xml.ws.policy.PolicyException: WSP0071: Multiple policy assertion >>>> creators try to register for namespace ' >>>> http://schemas.xmlsoap.org/ws/2005/02/rm/policy'. Old creator`s class: >>>> 'com.sun.xml.ws.rx.policy.spi_impl.RxAssertionCreator', new creator`s >>>> class: >>>> 'com.sun.xml.ws.rm.policy.spi_impl.RmAssertionCreator'. >>>> at >>>> com.sun.xml.ws.policy.sourcemodel.PolicyModelTranslator.<init>(PolicyModelTranslator.java:184) >>>> at >>>> com.sun.xml.ws.api.policy.ModelTranslator.<init>(ModelTranslator.java:81) >>>> at >>>> com.sun.xml.ws.api.policy.ModelTranslator.<clinit>(ModelTranslator.java:70) >>>> at >>>> com.sun.xml.ws.policy.BuilderHandler.getPolicies(BuilderHandler.java:97) >>>> at >>>> com.sun.xml.ws.policy.BuilderHandler.getPolicySubjects(BuilderHandler.java:105) >>>> at >>>> com.sun.xml.ws.policy.BuilderHandlerEndpointScope.doPopulate(BuilderHandlerEndpointScope.java:67) >>>> at com.sun.xml.ws.policy.BuilderHandler.populate(BuilderHandler.java:77) >>>> at >>>> com.sun.xml.ws.policy.PolicyMapBuilder.getNewPolicyMap(PolicyMapBuilder.java:103) >>>> at >>>> com.sun.xml.ws.policy.PolicyMapBuilder.getPolicyMap(PolicyMapBuilder.java:85) >>>> at >>>> com.sun.xml.ws.policy.PolicyWSDLParserExtension.postFinished(PolicyWSDLParserExtension.java:955) >>>> at >>>> com.sun.xml.ws.wsdl.parser.DelegatingParserExtension.postFinished(DelegatingParserExtension.java:187) >>>> at >>>> com.sun.xml.ws.wsdl.parser.WSDLParserExtensionFacade.postFinished(WSDLParserExtensionFacade.java:334) >>>> at >>>> com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:262) >>>> at >>>> com.sun.xml.ws.server.EndpointFactory.getWSDLPort(EndpointFactory.java:531) >>>> at >>>> com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:174) >>>> at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:505) >>>> at >>>> com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parseAdapters(DeploymentDescriptorParser.java:253) >>>> at >>>> com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:147) >>>> at >>>> com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:124) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>>> at java.lang.reflect.Method.invoke(Method.java:597) >>>> at >>>> com.sun.identity.wss.sts.STSContextListener.contextInitialized(STSContextListener.java:107) >>>> at >>>> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4523) >>>> at >>>> org.apache.catalina.core.StandardContext.start(StandardContext.java:5184) >>>> at com.sun.enterprise.web.WebModule.start(WebModule.java:326) >>>> at >>>> com.sun.enterprise.web.LifecycleStarter.doRun(LifecycleStarter.java:58) >>>> at >>>> com.sun.appserv.management.util.misc.RunnableBase.runSync(RunnableBase.java:304) >>>> at >>>> com.sun.appserv.management.util.misc.RunnableBase._submit(RunnableBase.java:176) >>>> at >>>> com.sun.appserv.management.util.misc.RunnableBase.submit(RunnableBase.java:192) >>>> at >>>> com.sun.enterprise.web.VirtualServer.startChildren(VirtualServer.java:1672) >>>> at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1231) >>>> at org.apache.catalina.core.StandardHost.start(StandardHost.java:955) >>>> at >>>> com.sun.enterprise.web.LifecycleStarter.doRun(LifecycleStarter.java:58) >>>> at >>>> com.sun.appserv.management.util.misc.RunnableBase.runSync(RunnableBase.java:304) >>>> at >>>> com.sun.appserv.management.util.misc.RunnableBase._submit(RunnableBase.java:176) >>>> at >>>> com.sun.appserv.management.util.misc.RunnableBase.submit(RunnableBase.java:192) >>>> at >>>> com.sun.enterprise.web.EmbeddedWebContainer$WebEngine.startChildren(EmbeddedWebContainer.java:453) >>>> at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1231) >>>> at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:533) >>>> at org.apache.catalina.startup.Embedded.start(Embedded.java:936) >>>> at com.sun.enterprise.web.WebContainer.start(WebContainer.java:873) >>>> at >>>> com.sun.enterprise.web.PEWebContainer.startInstance(PEWebContainer.java:790) >>>> at >>>> com.sun.enterprise.web.PEWebContainerLifecycle.onStartup(PEWebContainerLifecycle.java:84) >>>> at >>>> com.sun.enterprise.server.ApplicationServer.onStartup(ApplicationServer.java:442) >>>> at >>>> com.sun.enterprise.server.ondemand.OnDemandServer.onStartup(OnDemandServer.java:120) >>>> at com.sun.enterprise.server.PEMain.run(PEMain.java:411) >>>> at com.sun.enterprise.server.PEMain.main(PEMain.java:338) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>>> at java.lang.reflect.Method.invoke(Method.java:597) >>>> at com.sun.enterprise.server.PELaunch.main(PELaunch.java:412) >>>> |#] >>>> >>>> Is there any additional step I do not know required to change the >>>> certificate ? >>>> >>>> Thanks >>>> Pablo. >>>> >>>> -----Original Message----- >>>> From: jiandong....@sun.com [mailto:jiandong....@sun.com] Sent: Monday, >>>> November 02, 2009 8:09 PM >>>> To: stonehenge-dev@incubator.apache.org >>>> Subject: Re: Third interop test between Metro and .NET >>>> >>>> Pablo Cibraro wrote: >>>> >>>> >>>> >>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>> Reasonable since the client already has the certificate to identify it. >>>> We need to update Metro part for this. >>>> >>>> >>>> >>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> One possible reason is version mismatch since we have to use addressing >>>> Action header to identity and secure the message properly. >>>> Can you check if you use <sp:Trust13 and have something like >>>> wsap10:Action="http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue"; >>>> set in the wsdl? >>>> >>>> >>>> >>>> >>>>> 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." >>>>> >>>>> >>>>> >>>>> >>>> Can you get the request message for this? I'd like to see where we have >>>> this ValueType=" ". >>>> >>>> Thanks! >>>> >>>> Jiandong >>>> >>>> >>>> >>>> >>>>> Regards, >>>>> Pablo. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >> -- >> Ming Jin >> >> Consultant >> Thoughtworks, Inc >> Twitter: https://twitter.com/mingjin >> >> > > > > >
