Hey, thanks. Let see if we can get this scenario working :). I am now having
issues with the WSFederationClient,
Caused by: javax.faces.FacesException: javax.faces.FacesException: Cant set
managed bean property: samlAssertion.
at
com.sun.faces.application.ApplicationAssociate.createAndMaybeStoreManagedBeans(ApplicationAssociate.java:519)
at
com.sun.faces.el.ManagedBeanELResolver.getValue(ManagedBeanELResolver.java:82)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143)
at
com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:64)
at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:86)
at com.sun.el.parser.AstValue.getValue(AstValue.java:127)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:206)
at
com.sun.faces.config.ManagedBeanFactoryImpl.evaluateValueExpressionGet(ManagedBeanFactoryImpl.java:1003)
at
com.sun.faces.config.ManagedBeanFactoryImpl.setPropertiesIntoBean(ManagedBeanFactoryImpl.java:636)
at
com.sun.faces.config.ManagedBeanFactoryImpl.newInstance(ManagedBeanFactoryImpl.java:317)
at
com.sun.faces.application.ApplicationAssociate.createAndMaybeStoreManagedBeans(ApplicationAssociate.java:546)
... 80 more
Caused by: javax.faces.FacesException: Cant set managed bean property:
samlAssertion.
at
com.sun.faces.config.ManagedBeanFactoryImpl.setPropertiesIntoBean(ManagedBeanFactoryImpl.java:665)
at
com.sun.faces.config.ManagedBeanFactoryImpl.newInstance(ManagedBeanFactoryImpl.java:317)
at
com.sun.faces.application.ApplicationAssociate.createAndMaybeStoreManagedBeans(ApplicationAssociate.java:509)
... 90 more
Caused by: javax.el.ELException: java.lang.NoClassDefFoundError:
com/sun/jersey/api/client/Client
at javax.el.BeanELResolver.getValue(BeanELResolver.java:266)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143)
at
com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:64)
at com.sun.el.parser.AstValue.getValue(AstValue.java:138)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:206)
at
com.sun.faces.config.ManagedBeanFactoryImpl.evaluateValueExpressionGet(ManagedBeanFactoryImpl.java:1003)
at
com.sun.faces.config.ManagedBeanFactoryImpl.setPropertiesIntoBean(ManagedBeanFactoryImpl.java:636)
... 92 more
Caused by: java.lang.NoClassDefFoundError: com/sun/jersey/api/client/Client
at
com.sun.identity.wsfederation.client.WSFederationClient.<clinit>(WSFederationClient.java:45)
at
org.apache.stonehenge.stocktrader.service.CookieManager.getSamlAssertion(Unknown
Source)
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 javax.el.BeanELResolver.getValue(BeanELResolver.java:261)
... 98 more
Caused by: java.lang.ClassNotFoundException: com.sun.jersey.api.client.Client
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at
com.sun.appserv.server.util.ASURLClassLoader.loadClass(ASURLClassLoader.java:144)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
It looks like the jersey.client library is required. What I did was to download
and copy jersey-client-1.1.4.1.jar to Stonehenge\lib, and I modified the ant
file (build.xml) for the trader client to include this file as library.
<target name="war" depends="build">
<war warfile="${war.file}" webxml="web/WEB-INF/web.xml">
<webinf dir="${basedir}/web/WEB-INF">
<include name="faces-config.xml"/>
<include name="sun-web.xml"/>
<include name="facelets/**/*"/>
</webinf>
<zipfileset dir="${basedir}/web" includes="*.jsp"/>
<zipfileset dir="${basedir}/web" includes="*.xhtml"/>
<zipfileset dir="${basedir}/web" includes="*.jsf"/>
<zipfileset dir="${basedir}/web/css" prefix="css"/>
<zipfileset dir="${basedir}/web/images" prefix="images"/>
<classes dir="${build.classes.home}"/>
<lib dir="${lib.home}/facelets"/>
<lib dir="${lib.home}/commons"/>
<lib dir="${lib.home}/agent"/>
<lib dir="${lib.home}/mysql"/>
<lib dir="${lib.home}/mssql"/>
<lib dir="${lib.home}/jersey"/>
</war>
</target>
This did not work, so I also copied that jar to the JAVA_HOME\Lib and
JAVA_HOME\Lib\Endorsed folders. I could not make it work in any case. Any clue
about something missing here ?
Thanks
Pablo.
-----Original Message-----
From: jiandong....@sun.com [mailto:jiandong....@sun.com]
Sent: Wednesday, January 13, 2010 7:22 PM
To: stonehenge-dev@incubator.apache.org
Subject: Re: Third interop test between Metro and .NET
Pablo,
Nice to have you back.
import com.sun.identity.wsfederation.client.WSFederationClient;
Thanks!
Jiandong
Pablo Cibraro wrote:
> Hi Jiandong,
>
> Is this class WSFederationClient in any specific package that I need to
> import in the CookieManager ?
>
> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>>
>>
>
>
>
>
