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
