+ Start a Discussion
DemonsOutDemonsOut 

SSO via SAML 2.0-->Invalid Page Redirection

I'm using OpenSSO to authenticate with my SF developer account.  According tothe SAML Validator my SAML response is good.  This is supported by the Login History, which shows a successful login for my user via SAML Idp Initiated SSO.  Still, instead of getting directed into SF after login, I get redirected to the following error page:

 


Invalid Page Redirection
The page you attempted to access has been blocked due to a redirection to an outside website or an improperly coded link or button. Please contact your salesforce.com Administrator for assistance.

Click here to return to the previous page.


Here's the SAML Response:

 

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://login.salesforce.com/?saml=02HKiPoin4YWIEZVhRxAotsxXTE8snvZkcfnHVUoabFTp6uOXs180wMbR2" ID="s284c6b267aec8be2c66edcc163f7cf5a492522909" IssueInstant="2010-03-07T01:21:18Z" Version="2.0"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> http://www.abazaindustries.com:8080/opensso_abaza</saml:Issuer> <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="#s284c6b267aec8be2c66edcc163f7cf5a492522909"> <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>bbdtFNmHOCmOJDxBKRPBQMGWx/c=</DigestValue> </Reference> </SignedInfo> <SignatureValue> NyXQjGHDh7CEcmBaY5G8EcbP3nsALGkCR/dls5wy72hhvN4+EJlvD/fQuSIjxPrHl/nJJTXQJwwJ rJN6+8CBqBXPM+OAbfRzSY1MryIgi2gGxZgvYtve0VTIsJn+D86Uh6nJEbDODE9qlUEF+hpsZwgp qTehm8e0BzCRU8d0yNs=</SignatureValue> <KeyInfo> <X509Data> <X509Certificate> MIICQDCCAakCBEeNB0swDQYJKoZIhvcNAQEEBQAwZzELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh bGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMQwwCgYDVQQKEwNTdW4xEDAOBgNVBAsTB09w ZW5TU08xDTALBgNVBAMTBHRlc3QwHhcNMDgwMTE1MTkxOTM5WhcNMTgwMTEyMTkxOTM5WjBnMQsw CQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExDDAK BgNVBAoTA1N1bjEQMA4GA1UECxMHT3BlblNTTzENMAsGA1UEAxMEdGVzdDCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEArSQc/U75GB2AtKhbGS5piiLkmJzqEsp64rDxbMJ+xDrye0EN/q1U5Of+ RkDsaN/igkAvV1cuXEgTL6RlafFPcUX7QxDhZBhsYF9pbwtMzi4A4su9hnxIhURebGEmxKW9qJNY Js0Vo5+IgjxuEWnjnnVgHTs1+mq5QYTA7E6ZyL8CAwEAATANBgkqhkiG9w0BAQQFAAOBgQB3Pw/U QzPKTPTYi9upbFXlrAKMwtFf2OW4yvGWWvlcwcNSZJmTJ8ARvVYOMEVNbsT4OFcfu2/PeYoAdiDA cGy/F2Zuj8XJJpuQRSE6PtQqBuDEHjjmOQJ0rV/r8mO1ZCtHRhpZ5zYRjhRC9eCbjx9VrFax0JDC /FfwWigmrW0Y0Q==</X509Certificate> </X509Data> </KeyInfo> </Signature> <samlp:Status> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"> </samlp:StatusCode> </samlp:Status> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="s26d010fb96c415e8dd239c664b62a95b62ad186c3" IssueInstant="2010-03-07T01:21:18Z" Version="2.0"> <saml:Issuer> http://www.abazaindustries.com:8080/opensso_abaza</saml:Issuer> <saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" NameQualifier="http://www.abazaindustries.com:8080/opensso_abaza" SPNameQualifier="https://saml.salesforce.com"> xYNogS2tyRrH1DdZ1ASUD5BJZWlC</saml:NameID> <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:SubjectConfirmationData NotOnOrAfter="2010-03-07T01:31:18Z" Recipient="https://login.salesforce.com/?saml=02HKiPoin4YWIEZVhRxAotsxXTE8snvZkcfnHVUoabFTp6uOXs180wMbR2" /> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore="2010-03-07T01:11:18Z" NotOnOrAfter="2010-03-07T01:31:18Z"> <saml:AudienceRestriction> <saml:Audience>https://saml.salesforce.com</saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2010-03-07T01:21:18Z" SessionIndex="s2632afd2c7d9eee1430c180dbc8ffc4e1891c3b01"> <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> <saml:AttributeStatement> <saml:Attribute Name="ATTR_PHONE"> <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">555-555-5555</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion> </samlp:Response>

 

 

Best Answer chosen by Admin (Salesforce Developers) 
chuckmortimorechuckmortimore

You are seeing the redirect error because of the RelayState parameter you are passing in.   In the POST data, you are sending:

 

RelayState	http://www.abazaindustries.com:8080/opensso_abaza/validatorStatus.jsp

 

For security reasons we don't allow a relay state of a non-salesforce.com domain.   2 options here

 

  1. Don't send a RelayState parameter - we'll take the user to the home page
  2. Send a RelayState for a valid salesforce URL ( relative is preferred ), like: RelayState=/001/o which would take you to the Accounts tab

 Hope that helps!

All Answers

chuckmortimorechuckmortimore
This is most likely related to where you're trying to send the user after Single Sign-On has occured.   Are you passing a RelayState parameter in the HTTP?     Would it be possible to post the entire HTTP POST rather than just the SAMLResponse? 
DemonsOutDemonsOut

ChuckMortimore,

 

Thanks for taking the time to respond. Much appreciated.

 

Here's the POST information as displayed by FireBug

 

 

RelayState http://www.abazaindustries.com:8080/opensso_abaza/validatorStatus.jsp?s=sso&v=1&sendRedirectForValidationNow=true SAMLResponse PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6 cHJvdG9jb2wiIERlc3RpbmF0aW9uPSJodHRwczovL2xvZ2luLnNhbGVzZm9yY2UuY29tLz9zYW1s PTAySEtpUG9pbjRZV0lFWlZoUnhBb3RzeFhURThzbnZaa2NmbkhWVW9hYkZUcDZ1T1hzMTgwd01i UjIiIElEPSJzMmVkNGYyZDE2NGZkOTQ4OTMzMDhkMWE3ZjUxODMwN2RhN2VlMGFiOTkiIElzc3Vl SW5zdGFudD0iMjAxMC0wMy0wOVQwMjoyMjoxNFoiIFZlcnNpb249IjIuMCI+PHNhbWw6SXNzdWVy IHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iPmh0dHA6 Ly93d3cuYWJhemFpbmR1c3RyaWVzLmNvbTo4MDgwL29wZW5zc29fYWJhemE8L3NhbWw6SXNzdWVy PjxTaWduYXR1cmUgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiPg0K PFNpZ25lZEluZm8+DQo8Q2Fub25pY2FsaXphdGlvbk1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93 d3cudzMub3JnLzIwMDEvMTAveG1sLWV4Yy1jMTRuIyIvPg0KPFNpZ25hdHVyZU1ldGhvZCBBbGdv cml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyNyc2Etc2hhMSIvPg0KPFJl ZmVyZW5jZSBVUkk9IiNzMmVkNGYyZDE2NGZkOTQ4OTMzMDhkMWE3ZjUxODMwN2RhN2VlMGFiOTki Pg0KPFRyYW5zZm9ybXM+DQo8VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcv MjAwMC8wOS94bWxkc2lnI2VudmVsb3BlZC1zaWduYXR1cmUiLz4NCjxUcmFuc2Zvcm0gQWxnb3Jp dGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzEwL3htbC1leGMtYzE0biMiLz4NCjwvVHJhbnNm b3Jtcz4NCjxEaWdlc3RNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5 L3htbGRzaWcjc2hhMSIvPg0KPERpZ2VzdFZhbHVlPnVYZUJQYzhsL0RjUmdLWlZGeDZMVTNwdEZ4 bz08L0RpZ2VzdFZhbHVlPg0KPC9SZWZlcmVuY2U+DQo8L1NpZ25lZEluZm8+DQo8U2lnbmF0dXJl VmFsdWU+DQpwMDFVUFZ5K3ZvL0NNWEg5S3VrbTYyZnM0R0xIUytyeGl6dTZneEpaRWJTVWhaTHpZ enRtbTRDV3lWZVQ1aXUxN0pNQjd1OGZPMGp6DQpQRE8wZUovcmRZenR0dTZwWWJ3SkF2YjhONEZi OHZZdi8yZU54TUcwS2ZGbkVyalZwRDJ1NlR0cEFURVQ1VDB5T2RCYnhobUpjNmtMDQoyalZETUxH WStsNzZJcDFOUnZFPQ0KPC9TaWduYXR1cmVWYWx1ZT4NCjxLZXlJbmZvPg0KPFg1MDlEYXRhPg0K PFg1MDlDZXJ0aWZpY2F0ZT4NCk1JSUNRRENDQWFrQ0JFZU5CMHN3RFFZSktvWklodmNOQVFFRUJR QXdaekVMTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmgNCmJHbG1iM0p1YVdFeEZEQVNC Z05WQkFjVEMxTmhiblJoSUVOc1lYSmhNUXd3Q2dZRFZRUUtFd05UZFc0eEVEQU9CZ05WQkFzVEIw OXcNClpXNVRVMDh4RFRBTEJnTlZCQU1UQkhSbGMzUXdIaGNOTURnd01URTFNVGt4T1RNNVdoY05N VGd3TVRFeU1Ua3hPVE01V2pCbk1Rc3cNCkNRWURWUVFHRXdKVlV6RVRNQkVHQTFVRUNCTUtRMkZz YVdadmNtNXBZVEVVTUJJR0ExVUVCeE1MVTJGdWRHRWdRMnhoY21FeEREQUsNCkJnTlZCQW9UQTFO MWJqRVFNQTRHQTFVRUN4TUhUM0JsYmxOVFR6RU5NQXNHQTFVRUF4TUVkR1Z6ZERDQm56QU5CZ2tx aGtpRzl3MEINCkFRRUZBQU9CalFBd2dZa0NnWUVBclNRYy9VNzVHQjJBdEtoYkdTNXBpaUxrbUp6 cUVzcDY0ckR4Yk1KK3hEcnllMEVOL3ExVTVPZisNClJrRHNhTi9pZ2tBdlYxY3VYRWdUTDZSbGFm RlBjVVg3UXhEaFpCaHNZRjlwYnd0TXppNEE0c3U5aG54SWhVUmViR0VteEtXOXFKTlkNCkpzMFZv NStJZ2p4dUVXbmpublZnSFRzMSttcTVRWVRBN0U2WnlMOENBd0VBQVRBTkJna3Foa2lHOXcwQkFR UUZBQU9CZ1FCM1B3L1UNClF6UEtUUFRZaTl1cGJGWGxyQUtNd3RGZjJPVzR5dkdXV3ZsY3djTlNa Sm1USjhBUnZWWU9NRVZOYnNUNE9GY2Z1Mi9QZVlvQWRpREENCmNHeS9GMlp1ajhYSkpwdVFSU0U2 UHRRcUJ1REVIamptT1FKMHJWL3I4bU8xWkN0SFJocFo1ellSamhSQzllQ2JqeDlWckZheDBKREMN Ci9GZndXaWdtclcwWTBRPT0NCjwvWDUwOUNlcnRpZmljYXRlPg0KPC9YNTA5RGF0YT4NCjwvS2V5 SW5mbz4NCjwvU2lnbmF0dXJlPjxzYW1scDpTdGF0dXM+DQo8c2FtbHA6U3RhdHVzQ29kZSBWYWx1 ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnN0YXR1czpTdWNjZXNzIj4NCjwvc2FtbHA6 U3RhdHVzQ29kZT4NCjwvc2FtbHA6U3RhdHVzPjxzYW1sOkFzc2VydGlvbiB4bWxuczpzYW1sPSJ1 cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIiBJRD0iczJkYmZmZmJlYjAxNmM5 MmZjYjdhODg0NTA5NzVhMDJkZjEzMjM0MjU4IiBJc3N1ZUluc3RhbnQ9IjIwMTAtMDMtMDlUMDI6 MjI6MTRaIiBWZXJzaW9uPSIyLjAiPg0KPHNhbWw6SXNzdWVyPmh0dHA6Ly93d3cuYWJhemFpbmR1 c3RyaWVzLmNvbTo4MDgwL29wZW5zc29fYWJhemE8L3NhbWw6SXNzdWVyPjxzYW1sOlN1YmplY3Q+ DQo8c2FtbDpOYW1lSUQgRm9ybWF0PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6bmFtZWlk LWZvcm1hdDp0cmFuc2llbnQiIE5hbWVRdWFsaWZpZXI9Imh0dHA6Ly93d3cuYWJhemFpbmR1c3Ry aWVzLmNvbTo4MDgwL29wZW5zc29fYWJhemEiIFNQTmFtZVF1YWxpZmllcj0iaHR0cHM6Ly9zYW1s LnNhbGVzZm9yY2UuY29tIj5zbEtLTkJZTld0V2JjejIzazNVMmhXVG9SaVBMPC9zYW1sOk5hbWVJ RD48c2FtbDpTdWJqZWN0Q29uZmlybWF0aW9uIE1ldGhvZD0idXJuOm9hc2lzOm5hbWVzOnRjOlNB TUw6Mi4wOmNtOmJlYXJlciI+DQo8c2FtbDpTdWJqZWN0Q29uZmlybWF0aW9uRGF0YSBOb3RPbk9y QWZ0ZXI9IjIwMTAtMDMtMDlUMDI6MzI6MTRaIiBSZWNpcGllbnQ9Imh0dHBzOi8vbG9naW4uc2Fs ZXNmb3JjZS5jb20vP3NhbWw9MDJIS2lQb2luNFlXSUVaVmhSeEFvdHN4WFRFOHNudlprY2ZuSFZV b2FiRlRwNnVPWHMxODB3TWJSMiIvPjwvc2FtbDpTdWJqZWN0Q29uZmlybWF0aW9uPg0KPC9zYW1s OlN1YmplY3Q+PHNhbWw6Q29uZGl0aW9ucyBOb3RCZWZvcmU9IjIwMTAtMDMtMDlUMDI6MTI6MTRa IiBOb3RPbk9yQWZ0ZXI9IjIwMTAtMDMtMDlUMDI6MzI6MTRaIj4NCjxzYW1sOkF1ZGllbmNlUmVz dHJpY3Rpb24+DQo8c2FtbDpBdWRpZW5jZT5odHRwczovL3NhbWwuc2FsZXNmb3JjZS5jb208L3Nh bWw6QXVkaWVuY2U+DQo8L3NhbWw6QXVkaWVuY2VSZXN0cmljdGlvbj4NCjwvc2FtbDpDb25kaXRp b25zPg0KPHNhbWw6QXV0aG5TdGF0ZW1lbnQgQXV0aG5JbnN0YW50PSIyMDEwLTAzLTA5VDAyOjIy OjE0WiIgU2Vzc2lvbkluZGV4PSJzMjFmNzc0ZDI2NDA2MmI0Yzc1MzNkMTVkODA5Zjc5YzFkN2M2 ZThiMDEiPjxzYW1sOkF1dGhuQ29udGV4dD48c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj51cm46 b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5z cG9ydDwvc2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj48L3NhbWw6QXV0aG5Db250ZXh0Pjwvc2Ft bDpBdXRoblN0YXRlbWVudD48c2FtbDpBdHRyaWJ1dGVTdGF0ZW1lbnQ+PHNhbWw6QXR0cmlidXRl IE5hbWU9IkFUVFJfUEhPTkUiPjxzYW1sOkF0dHJpYnV0ZVZhbHVlIHhtbG5zOnhzPSJodHRwOi8v d3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8y MDAxL1hNTFNjaGVtYS1pbnN0YW5jZSIgeHNpOnR5cGU9InhzOnN0cmluZyI+NjA4MjM5MzA4MDwv c2FtbDpBdHRyaWJ1dGVWYWx1ZT48L3NhbWw6QXR0cmlidXRlPjwvc2FtbDpBdHRyaWJ1dGVTdGF0 ZW1lbnQ+PC9zYW1sOkFzc2VydGlvbj4NCjwvc2FtbHA6UmVzcG9uc2U+

 

 SF responds to the POST with the following message, before redirecting me to the page I referenced in my original post:

 

 

 

Failed to load source for: https://login.salesforce.com/?saml=02HKiPoin4YWIEZVhRxAotsxXTE8snvZkcfnHVUoabFTp6uOXs180wMbR2

 

 

 

 

chuckmortimorechuckmortimore

You are seeing the redirect error because of the RelayState parameter you are passing in.   In the POST data, you are sending:

 

RelayState	http://www.abazaindustries.com:8080/opensso_abaza/validatorStatus.jsp

 

For security reasons we don't allow a relay state of a non-salesforce.com domain.   2 options here

 

  1. Don't send a RelayState parameter - we'll take the user to the home page
  2. Send a RelayState for a valid salesforce URL ( relative is preferred ), like: RelayState=/001/o which would take you to the Accounts tab

 Hope that helps!

This was selected as the best answer
DemonsOutDemonsOut

Once I excluded the the RelayState POST parameter, SSO worked seamlessly.  Thanks so much for your help.  BTW, since I have your attention, I was wondering if I could get any info on how, if at all, SF supports Single Sign Out via SAML.

 

Thanks again!

chuckmortimorechuckmortimore

Glad to hear it's working.

 

We do not currently support Single Logout.    We've done some investigation / prototyping but it's not ready for primtetime, and we haven't seen too much customer demand yet.   We seem to be in a phase of federation adoption where most folks are still working on getting signed-in...

 

I'd appreciate a quick summary of your use-case for single logout if you have a moment.   It would be useful as we consider work going forward.

 

Once again - glad you're up and running!

tnstns

I have a similar issue and would appreciate any help.

 

The following POST returns an error "The URL has moved <a href="http://cs4.salesforce.com/_nc_external/system/security/saml/SamlError">here</a>"

 

The URL being used to POST to is: https://cs4.salesforce.com/?saml=EK03Almz90FLhbSDnLdkkeSDBlWpQazl7zj.DW2qxoeN0rnIrudrbUH.Tw

 

The Relay State is: https://cs4.salesforce.com/knowledge/knowledgeHome.apexp

 

And the xml is:

<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" ID="pcjokhjehldagmecmfefiaadffiejfabgpkbmgpp" IssueInstant="2010-12-04T05:34:11Z" Version="2.0">
  <Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://ingsso.ingenuity.com/cas</Issuer>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
  </samlp:Status>
  <Assertion ID="afajiciaccjdlbpfahkjngdifeehkpgkbbkajjkf" IssueInstant="2010-11-30T21:42:11Z" Version="2.0">
    <Issuer>https://ingsso.ingenuity.com/cas</Issuer>
    <Subject>
      <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified">166</NameID>
      <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData Recipient="https://cs4.salesforce.com/?saml=EK03Almz90FLhbSDnLdkkeSDBlWpQazl7zj.DW2qxoeN0rnIrudrbUH.Tw" NotOnOrAfter="2010-12-04T05:44:11Z" InResponseTo="ejfeelhihkjknhlghljcfckebjonkmmnhaicjbcp" />
      </SubjectConfirmation>
    </Subject>
    <Conditions NotBefore="2010-12-04T05:29:11Z" NotOnOrAfter="2010-12-04T05:44:11Z">
      <AudienceRestriction>
        <Audience>https://cs4.salesforce.com/?saml=EK03Almz90FLhbSDnLdkkeSDBlWpQazl7zj.DW2qxoeN0rnIrudrbUH.Tw</Audience>
      </AudienceRestriction>
    </Conditions>
    <AuthnStatement AuthnInstant="2010-12-04T05:34:11Z">
      <AuthnContext>
        <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
      </AuthnContext>
    </AuthnStatement>
    <AttributeStatement>
      <Attribute Name="portal_id">
        <AttributeValue>06050000000HXWY</AttributeValue>
      </Attribute>
      <Attribute Name="organization_id">
        <AttributeValue>00DP000000052j4</AttributeValue>
      </Attribute>
    </AttributeStatement>
  </Assertion>
</samlp:Response>

 

chuckmortimorechuckmortimore

Hi tns....

 

It's pretty tough to tell what is wrong simply by looking at your assertion.   Fortunately, the SAML Assertion Validator is there to help.    If you click on Single Sign On settings in Setup ( where you configured SAML ) there is a button for the Assertion Validator.   Click on this, and it will attempt to process your assertion and tell you what is wrong with it.    What's really nice is that it remembers the last SAML error for you automatically, so you don't even need to capture the assertion.   You can also paste on in directly if need be.

 

Take a look at the output of that tool and it should be clear.   If not, post the results and we can get you pointed in the right direction.

tnstns

Thanks. Yes, we have validated the POST several times but the results are not helpful (or perhaps we are not interpreting them correctly). Seems like a minor issue that we can't nail down.


Btw, we are trying to use SSO to the Customer Support Portal if that makes a difference in this discussion. Some documentation indicated that:

  • SAML 1.1: append as query string parameters on the URI https://saml.salesforce.com? and place this entire string in the TARGET field on the HTTP POST binding. For example: https://saml.salesforce.com/?mySsoStartPage=https%3A%2F%2Fwww.customer.org%2Flogin%2F&startURL=%2F001%2Fo
  •  

    For SAML 2.0, do we need to do something different? If so, what is the TARGET field and where do I have the developer make that change?

     

    We are posting to: https://cs4.salesforce.com/?saml=EK03Almz90FLhbSDnLdkkeSDBlWpQazl7zj.DW2qxoeN0rnIrudrbUH.Tw

     

    With a relay state of: https://cs4.salesforce.com/knowledge/knowledgeHome.apexp

     

    Even without the relay state, no connection. Login History does nto show any entry in SFDC.

     

    >>>>>>>>>>>>>>>>>>>>
    Below are the validation results, followed by the xml used for the validation.

     

    SAML Validator

    Your organization is configured to use SAML Version 2.0

    Results

     

    1. Validating the Status

      Ok

    2. Checking that the assertion contains a reference to a user

      Ok

    3. Looking for an Authentication Statement

      Ok

    4. Looking for a Conditions statement

      Ok

    5. Checking that the timestamps in the assertion are valid

      Current time is after notOnOrAfter in Conditions

      Current time is: 2010-12-05T19:56:04.554Z

      Time limit in Conditions, adjusted for skew, is: 2010-11-30T21:55:11.000Z

      Timestamp of the response is outside of allowed time window

      Current time is: 2010-12-05T19:56:04.554Z

      Timestamp is: 2010-11-30T21:42:11.000Z

      Allowed skew in milliseconds is 480000

    6. Checking that the Attribute namespace matches, if provided

      Not Provided

    7. Miscellaneous format confirmations

      Ok

    8. Confirming Issuer matches

      Ok

    9. Confirming a Subject Confirmation was provided and contains valid timestamps

      Current time is later than SubjectConfirmationData's notOnOrAfterField

      Current time is: 2010-12-05T19:56:04.561Z

      NotOnOrAfter is: 2010-11-30T21:52:11.000Z

    10. Checking that the Audience matches, if provided

      Ok

    11. Checking the Recipient

      Ok

    12. Validating the Signature

      Ok

    13. Checking that the Site URL Attribute contains a validate site url, if provided

      Not Provided

     


    Subject: 166

    AssertionId: lgmilkhpdokociojdfmfmmehjnjbpmnkkeeppgfi

     

    XML

    <?xml version="1.0" encoding="UTF-8"?>

    <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" IssueInstant="2010-11-30T21:42:11Z" Version="2.0"><Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://ingsso.ingenuity.com/cas</Issuer><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments" /><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /><Reference URI=""><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /><DigestValue>/eVC2rUSqV+lK72OQx0K6lYeF78=</DigestValue></Reference></SignedInfo><SignatureValue>VenRGPIhzMcD8Y0O3RE+ocRSGsyiZtfNIfYuiNlWB6QA7g/8wrPgoFPFuljrOQ//hyTo+v15kVqX

    GkqBYQy7Umf4pyRoqzoikMQJrWgaozaqyKk9w7pdWqZY4ZtYA1EvmO1o/1Xobk3UfhT3MfklrVNR

    ZZ/8dscE/3ItMMGiYyQ=</SignatureValue><KeyInfo><KeyValue><RSAKeyValue><Modulus>upGoJ0PvbIvdjJd8scEDKUCmpnkrBsRWay1eTt6LihQX2GU1++1G2NTlVW1lu8datp1atKi7l6HP

    TIcHS3Dd9bEp/ZL7ijedYrH4lfv0PAOnSfoX7ZKfxHnz+vr0YZQhYoL5CRiffIN1UbVEji5HT3Vy

    oUnVO2SGfnug4dDKbtk=</Modulus><Exponent>AQAB</Exponent></RSAKeyValue></KeyValue></KeyInfo></Signature><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></samlp:Status><Assertion IssueInstant="2010-11-30T21:42:11Z" Version="2.0"><Issuer>https://ingsso.ingenuity.com/cas</Issuer><Subject><NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified">166</NameID><SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><SubjectConfirmationData NotOnOrAfter="2010-11-30T21:52:11Z" Recipient="https://cs4.salesforce.com/?saml=EK03Almz90FLhbSDnLdkkeSDBlWpQazl7zj.DW2qxoeN0rnIrudrbUH.Tw" /></SubjectConfirmation></Subject><Conditions NotBefore="2010-11-30T21:37:11Z" NotOnOrAfter="2010-11-30T21:52:11Z"><AudienceRestriction><Audience>https://saml.salesforce.com</Audience></AudienceRestriction></Conditions><AuthnStatement AuthnInstant="2010-11-30T21:42:11Z"><AuthnContext><AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef></AuthnContext></AuthnStatement><AttributeStatement><Attribute><AttributeValue>06050000000HXWY</AttributeValue></Attribute><Attribute><AttributeValue>00DP000000052j4</AttributeValue></Attribute></AttributeStatement></Assertion></samlp:Response>

     

chuckmortimorechuckmortimore

For SAML 2.0, you need to add the portal id and org id as attributes of the SAML assertion.   You can find an example of what we expect here:

 

https://na1.salesforce.com/help/doc/user_ed.jsp?section=help&target=sso_saml_assertion_examples.htm&loc=help&hash=sample_asserts_for_portals

tnstns

The portal id and the org id ARE included in the xml I posted in my last response. Could you please review the xml and the validation resutls from my prior post or would you like me to re-submit all that detail?

chuckmortimorechuckmortimore

Looking at the SAML Assertion echo'd back from the validator that you posted, I see your Portal IDs, but they don't seem to have any attribute names.   Here's what I see

 

 

<AttributeStatement>
<Attribute>
<AttributeValue>06050000000HXWY</AttributeValue>
</Attribute>
<Attribute>
<AttributeValue>00DP000000052j4</AttributeValue>
</Attribute>
</AttributeStatement>
The Attribute elements really need names so we can tell what is what.   I see the names in your earlier post, but not here.  If it shows up like this, we'll simply ignore these attributes. Can you double check what you're sending to us?
-cmort

 

tnstns

You wouldn't happen to be attending Dreamforce where we could perhaps meet to dicsuss this in person, would you?

tnstns

For some reason, when I copy/paste the xml, it does not display the Attribute names even though they are included:

Attribute Name="portal_id" ><AttributeValue>06050000000HXWY

Attribute Name="organization id" ><AttributeValue>00DP000000052j4

 

 

VALIDATOR results:

1. Validating the Status
  Ok
2. Checking that the assertion contains a reference to a user
  Ok
3. Looking for an Authentication Statement
  Ok
4. Looking for a Conditions statement
  Ok
5. Checking that the timestamps in the assertion are valid
  Current time is after notOnOrAfter in Conditions
  Current time is: 2010-12-07T07:16:28.917Z
  Time limit in Conditions, adjusted for skew, is: 2010-11-30T21:55:11.000Z
  Timestamp of the response is outside of allowed time window
  Current time is: 2010-12-07T07:16:28.917Z
  Timestamp is: 2010-11-30T21:42:11.000Z
  Allowed skew in milliseconds is 480000
6. Checking that the Attribute namespace matches, if provided
  Not Provided
7. Miscellaneous format confirmations
  Ok
8. Confirming Issuer matches
  Ok
9. Confirming a Subject Confirmation was provided and contains valid timestamps
  Current time is later than SubjectConfirmationData's notOnOrAfterField
  Current time is: 2010-12-07T07:16:28.918Z
  NotOnOrAfter is: 2010-11-30T21:52:11.000Z
10. Checking that the Audience matches, if provided
  Ok
11. Checking the Recipient
  Ok
12. Validating the Signature
  Ok
13. Checking that the Site URL Attribute contains a validate site url, if provided
  Not Provided

 


Subject: 166

AssertionId: lgmilkhpdokociojdfmfmmehjnjbpmnkkeeppgfi

jasmina.hodzic1.389105721853305E12jasmina.hodzic1.389105721853305E12
An old thread, but I'll try: is the Single Logout fully implemented now? We are experiencing some trouble (I don't have the full SAML-assertion right now, but will obtain if/when necessary) and we are not sure if the problem is in the meta-data or lack of support. Thanks in advance for any help anyone can provide regarding this :-)
Jignesh TankJignesh Tank

For the timestamps assertion issue,
it seems your OpenAM instance timezone and SalesForce server timezone is not matching. Check the instance's timezone setting. If it's a VM machine check at /etc/init.d/ntpd and /etc/localtime. Map the same timezone as per the SalesForce server. SalesForce server uses GMT by default.