Hi Jiandong, I was on vacations, so I did not have much time to test the patches. I will try to do it this week.
Thanks Pablo. -----Original Message----- From: jiandong....@sun.com [mailto:jiandong....@sun.com] Sent: Tuesday, January 05, 2010 7:56 PM To: stonehenge-dev@incubator.apache.org Subject: Re: Third interop test between Metro and .NET It may take two weeks for express 9 to be officially released. Also we have Metro 2.0 released: https://metro.dev.java.net/2.0/, which should be used. We have been using Metro nightly build for testing. Pablo, Have you tested it for this "Third interop test between Metro and .NET" with the changes outlined in the previous email? Thanks for the effort. Jiandong Jiandong Guo wrote: > Hi Nick, > > It should be available in OpenSSO express 9. > Express 9 has been announced > (http://www.sun.com/aboutsun/pr/2009-12/sunflash.20091215.1.xml), > but looks like they have not made it available to download. I will > check about and get back. > > Thanks! > > Jiandong > > Nick Hauenstein wrote: >> Hello, >> >> I was wondering if the change mentioned in the OpenSSO nightly has >> made it into the Express release yet. I ask because the OpenSSO >> download page mentions that OpenSSO Express 8 is the latest release >> [1], but the release notes are from September 2009 [2]. Were you >> referring to OpenSSO Express 9? >> >> Thanks! >> >> - Nick >> >> [1] https://opensso.dev.java.net/public/use/index.html >> [2] http://wikis.sun.com/display/OpenSSO/OpenSSO+Express+8+Release+Notes >> >> -----Original Message----- >> From: jiandong....@sun.com [mailto:jiandong....@sun.com] >> Sent: Sunday, December 13, 2009 12:15 AM >> To: stonehenge-dev@incubator.apache.org >> Subject: Re: Third interop test between Metro and .NET >> >> Pablo, >> >> We have a solution for this. Original the issued assertion from IP is >> only targeted >> for the SP, not supposed to be reusable once contained from the session >> on the Web application. >> >> Now it is enhanced with an API for getting the original assertion from >> SP through an REST based service. >> To use this: >> >> 1. Get the latest OpenSSO nightly from here: >> http://download.java.net/general/opensso/nightly/. >> It should be available on Tuesday (15-Dec-2009 's build. Then the change >> will be in a stable express release >> at the end of next week. You need to take new opensso.war and >> openssoclientsdk.jar >> (to replace the openssoclientsdk.jar in J2EE policy agent as well as the >> one used to build trader client in >> stonehenge\lib\agent). >> >> 2. In STSFilter, instead of get the assertion and put it in the cookie >> (it is too large for cookie in any case), >> just get the assertion id with >> >> String tokenID = ssoToken.getTokenID().toString(); >> >> and put it in the cookie: >> >> Cookie assertionCookie = new Cookie("Assertion", tokenID); >> >> 3. In CookieManager, getSamlAssertion(): >> >> if (requestCookie != null) { >> String assertionId = requestCookie.getValue(); >> >> // may be obtained from configuration >> String url = >> "http://sp.stonehenge.com:8080/opensso/federationws/wsfederationservice";; >> >> String samlAssertion = >> WSFederationClient.getUserSAMLAssertion(java.net.URLEncoder.encode(assertionID), >> >> url, null, null); >> return samlAssertion; >> } >> >> 4. With the latest opensso war and client jar, you don't need to use the >> patch provided any more. >> It also contains a fix for the NPE for Fifth interop with AppliesTo. >> >> Thanks! >> >> Jiandong >> >> >> Pablo Cibraro wrote: >> >>> That's great. Thanks a lot for looking into this. >>> >>> -----Original Message----- >>> From: jiandong....@sun.com [mailto:jiandong....@sun.com] >>> Sent: Monday, November 16, 2009 4:35 AM >>> To: stonehenge-dev@incubator.apache.org >>> Subject: Re: Third interop test between Metro and .NET >>> >>> Pablo, >>> >>> Ok. I traced through all the steps and found out the problem is >>> actually at the starting point that the assertion sting is already >>> modified from the original one with >>> String assertion = ssoToken.getProperty("Assertion"); >>> in STSFilter. >>> >>> Actually it uses toString method in : >>> http://fisheye5.atlassian.com/browse/opensso/products/federation/library/source/com/sun/identity/saml/assertion/AssertionBase.java?r=1.2 >>> >>> which creates a new assertion Element from the existing one. >>> Some change required in the patch file we have for OpenSSO. >>> >>> I will get back after I got it fixed with OpenSSO. >>> >>> Thanks! >>> >>> Jiandong >>> >>> >>> Pablo Cibraro wrote: >>> >>> >>>> Hi Jiandong, >>>> >>>> I went with the first approach (encoding the token as base64), and >>>> now geneva receives the token without the string manipulations. >>>> However, for some reason, the signature validation is still >>>> failing, it looks like the error is somewhere else in the metro. >>>> >>>> I also tried to store the saml token string in a static variable, >>>> but that produced the same results. >>>> >>>> Could it be an issue with these two lines ?. >>>> >>>> XMLStreamReader reader = >>>> XMLInputFactory.newInstance().createXMLStreamReader(stringReader); >>>> Element element = SAMLUtil.createSAMLAssertion(reader); >>>> >>>> Are you validating the signature of the ActAs token (SAML token) in >>>> the metro active STS ?. >>>> >>>> Thanks >>>> Pablo. >>>> >>>> -----Original Message----- >>>> From: jiandong....@sun.com [mailto:jiandong....@sun.com] >>>> Sent: Tuesday, November 10, 2009 2:03 PM >>>> To: stonehenge-dev@incubator.apache.org >>>> Subject: Re: Third interop test between Metro and .NET >>>> >>>> Ok. Some ways to get around it: >>>> >>>> 1. store Base64 of a stream of the assertion in the cookie, instead of >>>> the assertion string itself. >>>> >>>> or >>>> >>>> 2. In CookieManager, have a hash map for (assertionId, assertion) >>>> pairs >>>> and have assertionId in the cookie instaed of the whole assertion. >>>> Use CookieManager.getInstance() in both places to get per VM >>>> instance of >>>> CookieManager. >>>> >>>> or >>>> >>>> 3. Use ThreadLocal to store the assertion for the current user. >>>> >>>> ... >>>> >>>> Thanks! >>>> >>>> Jiandong >>>> >>>> Pablo Cibraro wrote: >>>> >>>> >>>> >>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>> >>> >> >> > >
