I had a look to the configuration and I'm wondering why the Security Token Request is sent to the CXF service instead of your STS.
Originally, you raised the issue that the SAML token can't be validated. But meanwhile, we face an issue one step before where the SAML token should be issued by the STS. Acording to your client configuration: <issuer address="http://stsbli.cloudapp.net:8080/STSService.svc/IWSTrust13"; binding="ws2007HttpBinding" bindingConfiguration="http://srvsk01.skdevel.local/WCFTestSTS/Service.svc/IWSTrust13"; > The STS request should be sent to the sts deployed at stsbli.cloudapp.net. Any idea why .NET sends it to the application service instead? According to your configuration, a symmetric key is generated: <message algorithmSuite="Default" issuedKeyType="SymmetricKey" negotiateServiceCredential="true"> The requested token type (issuedTokenType="string") is not configured which means it is left to the STS to decide what kind of token should be issued. I'm not sure about the impact of negotiateServiceCredential. Let's assume you can sort out the issue that the STS request is sent again to your STS instance instead of the CXF application service. The question then is how is the symmetric key shared between the service consumer and service provider. <?xml version="1.0"?> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" MinorVersion="1" AssertionID="_2bea327c-8791-4bd2-9f98-5690c0c6a83b" Issuer="BLISTS" IssueInstant="2011-11-09T22:47:38.202Z"> <saml:Conditions NotBefore="2011-11-09T22:47:38.124Z" NotOnOrAfter="2011-11-09T23:47:38.124Z"> <saml:AudienceRestrictionCondition> <saml:Audience>http://66.211.102.200/gen4/services/AssessmentDataService</saml:Audience> </saml:AudienceRestrictionCondition> </saml:Conditions> <saml:AttributeStatement> <saml:Subject> <saml:SubjectConfirmation> <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#";> <trust:BinarySecret xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512";>sYjbfcODXJg0oBL0EPlCMlUJ2SZnjk/51e2rDs+2e+E=</trust:BinarySecret> </KeyInfo> </saml:SubjectConfirmation> </saml:Subject> <saml:Attribute AttributeName="Name" AttributeNamespace="http://www.bli.org/claims";> <saml:AttributeValue>roccbufalino1</saml:AttributeValue> </saml:Attribute> <saml:Attribute AttributeName="IDNamespace" AttributeNamespace="http://www.bli.org/claims";> <saml:AttributeValue>http://www.bli.org/Rocketship/</saml:AttributeValue> </saml:Attribute> <saml:Attribute AttributeName="ID" AttributeNamespace="http://www.bli.org/claims";> <saml:AttributeValue>123111111111111111111</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#";> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <ds:Reference URI="#_2bea327c-8791-4bd2-9f98-5690c0c6a83b"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <ds:DigestValue>1cIz27KwzN0gwLkDSLolHTxaAMQ19YsVcF3eV1sA/68=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>t1vCq6MWMWupEDcfv/8b+FOCcb8bi7gIbBNM9XCLsIjm20xMPla5u43DjPaRb2+rPdnlVeNt/s/8Id/zxvPmBqIohdJY3ZeAC0/i+DLV+8tMdA/q6azSUjgZHKniUtqPjH6B5aLYm3niwkqivwhWCcl3txVjfbtjoxDTUmMendaDxZ80zHmIy73vzf1nNo+SokdGvwEbQY8RKSYXnUoXXP2oAkyUSG2efr/41eXkeOd+nLdCWLKEhDJCWYNEs1KlneJclh9Fu15DRmnihjeV3eFDFy1xmIXQ8IiVI+78CYvcPN7HMDSKOkDSQs3DmNQaamlxTYkMN0AMYwwEhcyWsA==</ds:SignatureValue> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#";> <X509Data> <X509Certificate>MIIC5DCCAcygAwIBAgIQbDQulAkeX7ROQqIwV6TAHDANBgkqhkiG9w0BAQUFADAWMRQwEgYDVQQDEwtTVFNUZXN0Q2VydDAeFw0xMTAzMzAxNTA4NDJaFw0xMjAzMjkyMTA4NDJaMBYxFDASBgNVBAMTC1NUU1Rlc3RDZXJ0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu56LAvEEYI7mI85ufyLS8MjuU5uPlgH9FUtE/YxPNIwsRe8+GZcXWHefuU0MV6m06K4GMeUq2i4E0ciKTsqnQhs0eqHt3WgH8uaF7DAz6sxzLpbUYWG7sGq0v3oanYv0S3+cfWyERvwYpdTmzqRRTNLRv371FIycc13LF67ZvpXZKEl0rkSfL8p6O6KHPQz5CduP3N+/3pjTsKsl/iNjM8K3Vi1MCb5lWeCBBig7yT9ICwWCkkDJpGJsksCanw8uM4eoRP3aY41EtPnA8Gvt5qVTMnn2JJGgxklegVUmsYtbBiziJCNWIa9loTEg5MbrzhQ5WSptV4HTviCSFqAPgwIDAQABoy4wLDALBgNVHQ8EBAMCBPAwHQYDVR0OBBYEFCAC194orTY0yHGxY/O+5fm+GHtjMA0GCSqGSIb3DQEBBQUAA4IBAQC4fo83cVW+Q8kNhn9bWSh9hOynuv1mTNPtgAxS37fifziexnK+LYe4uQNzAuGlgusxwQS1izSP5S3dRyOjzqrT+H4ZBeWwX9rTkmlyOtnGQIwyA5jwDeRqcPMgU9XJf5NwA2W88lJDTijRNIG6RCBQcusflqc4/DvYZmRlRX8XGjgOwf4Zw4pATMfA67CG/NDJXPbTHqTbJihdWjJXQODjocU1KabAXlIxPkwJFh8cf1dRDvYN3xVOmjgHpQ82G6RA4TXdTJKcU0yO8PHsVrOGmjYjDbVgThHRdzLvpBZG6ZD0O/i8C2gavoguIgRBnBCT4b4DEDLfVnebApzIFnVl</X509Certificate> </X509Data> </KeyInfo> </ds:Signature> </saml:Assertion> What is in the BinarySecret and against what should CXF process the proof-of-possession requirement? ------ Oliver Wulff http://owulff.blogspot.com Solution Architect Talend Application Integration Division http://www.talend.com ________________________________________ Von: satya [[email protected]] Gesendet: Montag, 9. Januar 2012 22:38 Bis: [email protected] Betreff: Re: AW: General security error (Provided SAML token does not contain a suitable key) The following is the configuration from the .net client. The configuration works with .net services <system.serviceModel> <client> <endpoint address="http://66.211.102.200/gen4/services/AssessmentDataService"; binding="ws2007FederationHttpBinding" bindingConfiguration="WS2007FederationHttpBinding_IAssessmentDataService" contract="ServiceReference2.IAssessmentDataService" name="WSHttpBinding_IAssessmentDataService" behaviorConfiguration="clientEndpointCredential"> <identity> <certificate encodedValue="" /> </identity> </endpoint> </client> <behaviors> <endpointBehaviors> <behavior name="clientEndpointCredential"> <clientCredentials> <clientCertificate storeName="My" storeLocation="LocalMachine" x509FindType="FindBySubjectName" findValue="BLITokenRequest" /> </clientCredentials> </behavior> </endpointBehaviors> <serviceBehaviors/> </behaviors> <bindings> <ws2007FederationHttpBinding> <binding name="WS2007FederationHttpBinding_IAssessmentDataService" > <security mode="Message"> <message algorithmSuite="Default" issuedKeyType="SymmetricKey" negotiateServiceCredential="true"> <issuer address="http://stsbli.cloudapp.net:8080/STSService.svc/IWSTrust13"; binding="ws2007HttpBinding" bindingConfiguration="http://srvsk01.skdevel.local/WCFTestSTS/Service.svc/IWSTrust13"; > <identity> <certificate encodedValue="*" /> </identity> </issuer> <issuerMetadata address="http://localhost:56636/Hybrid.STS/mex"; /> </message> </security> </binding> </ws2007FederationHttpBinding> <ws2007HttpBinding> <binding name="http://srvsk01.skdevel.local/WCFTestSTS/Service.svc/IWSTrust13";> <security mode="Message"> <message clientCredentialType="Certificate" negotiateServiceCredential="false" algorithmSuite="Default" establishSecurityContext="false" /> </security> </binding> </ws2007HttpBinding> </bindings> </system.serviceModel> -- View this message in context: http://cxf.547215.n5.nabble.com/Re-General-security-error-Provided-SAML-token-does-not-contain-a-suitable-key-tp4990489p5132596.html Sent from the cxf-dev mailing list archive at Nabble.com.
