Symantec Access Management

Has anyone succesfully deployed single sign on for the Salesforce for Outlook plugin?  We've setup SDP initiated SSO, and it is working correctly from the browser, but the plugin for outlook is not working.

We've followed this document which was provided by CA Support, https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2052-ENU/Bookshelf_Files/PDF/siteminder_fed_partnership_enu.pdf

I saw this thread in the salesforce community, but it seemed rather old.

https://success.salesforce.com/answers?id=90630000000ghKOAAY

Based on the old article it was not compatible because of the binds - Latest release of SSO support POST Binding, have you tried this ?

Enable SAML 2.0 HTTP-POST Binding - CA Single Sign-On - 12.52 SP2 - CA Technologies Documentation 

Thanks for the reply,

On the salesforce settings I have  the Servide Provider Initiated Request Binding set to HTTP Redirect, as opposed to the other option of HTTP POST.

On the Siteminder configuration I have Authentication Request binding checked as HTTP-Redirect and HTTP-POST.  BOth are checked.

For SSO Binding I have HTTP-Post check.

So I should try HTTP POST on salesforce side, and uncheck it on the Siteminder side?  I'll give it a try and let you know...

 With HTTP-Redirect unchecked on the SM side, the outlook plugin still fails.

When I changed it to HTTP POST on the Salesforce side, SDP initiated SAML broke so I reverted the change. This is what I've gotten in the logs.

[09/12/2016][09:24:37][27241][3129981840][341d4945-74b5e522-51774ba7-341c32e6-8abbee3f-ac][SSO.java][doGet][SAML2 Single Sign-On Service received GET request.]
[09/12/2016][09:24:37][27241][3129981840][341d4945-74b5e522-51774ba7-341c32e6-8abbee3f-ac][FWSBase.java][doRequestLog][Requesting Host: 136.184.89.191 Requesting Host IP: 136.184.89.191 Request protocol: HTTP/1.1 Request was secure: false Authentication type: null]
[09/12/2016][09:24:37][27241][3129981840][341d4945-74b5e522-51774ba7-341c32e6-8abbee3f-ac][SSO.java][doGet][Query String: null]
[09/12/2016][09:24:37][27241][3129981840][341d4945-74b5e522-51774ba7-341c32e6-8abbee3f-ac][SSO.java][doGet][Transaction with ID: 341d4945-74b5e522-51774ba7-341c32e6-8abbee3f-ac failed. Reason: NO_SAML_REQUEST_OR_SPID]
[09/12/2016][09:24:37][27241][3129981840][341d4945-74b5e522-51774ba7-341c32e6-8abbee3f-ac][SSO.java][doGet][No SAMLRequest or SPID parameter in request to SAML2 Single Sign-On Service]
[09/12/2016][09:24:37][27241][3129981840][341d4945-74b5e522-51774ba7-341c32e6-8abbee3f-ac][SSO.java][doGet][Ending SAML2 Single Sign-On Service request processing with HTTP error 400]
[09/12/2016][09:24:37][27241][3129981840][341d4945-74b5e522-51774ba7-341c32e6-8abbee3f-ac][ErrorRedirectionHandler.java][redirectToErrorPage][Sending HTTP Error 400 ]

Hi Jim,

Is the resolved?

I'm also running into the same issue.

Thanks

Not resolved yet.  We're still troubleshooting this.  Salesforce is going to provide custom java code to grab the relaystate on the login page.

Right now it will work on the 2nd try, we think it's due to an encoding issue.

Thank you very much for the reply.

We'll also contact salesforce support.

Hi Ujwol/Jim,

I found something regrading relay state that it sends IDP (CA SSO) when it is accessed from outlook plugin.

&RelayState=/setup/secur/RemoteAccessAuthorizationPage.apexp?display=popup&source=CAAAAVhvCW-3ME8wUjAwMDAwMDAwMDA1AAAAzAkx-nWbjP29NGglbb0uQr3ZZg2kU6Bcf8rmhsY9rOG1ZlwE0PqF0eKEA004bMcfHk3BSJ8pWNj1I54UrnB2ZTpObNNT_WwLSwjWjW8isRxk6i5eTzBzDoSgWJLR3owHz6s8V2nj8Qn8tVQ3ajFyhU8ifKvGCVz0hGMYOPUeiljrfwFerf91QpOW7_0QvvjywWFNNr55RefKKnUnnVTB1CsnFQMAVuJQ9-JTQqUbtIfUGAR-nYwOVrqxSqW30ttK94EBpEcGowtGs2io7RMs60U1B7-ynfKY827DMhcPGfaYNLv5i0k-U9l6vLoHJ57azzXbcHeWf-lqXcG_1esHZEcGJVfvf1TjVIWMufrwpi0cqEgSo5fiLhtefuPaX-eJUMVl-JeZ8Bqvd6DX5QNKwQrxpPW4kjv5U0AWN6df4xpV2j5LLwXv9GFg87_vpBpid1A5a5u95-DIMtjrMUJSNvqRUn8AXiswSoWZtWJzNiu-S4PC2MuVASCsKQIiTOF-MbLvNvxQyqRU6VVIDd6Po%3D 

when it pass above relay state string to IDP then it gives 404 error.

Where as when I trim the RelayState to &RelayState=/setup/secur/RemoteAccessAuthorizationPage.apexp and sends to IDP then it redirects IDP login for authentication and after successful authentication it redirects to relay state URL.

Do we have any limitation on relay state URL length when SP uses HTTP redirect binding when sending request to IDP?

FYI.

I found this article from below technical note and it mentions on page 16.

 http://www.ca.com/us/services-support/ca-support/ca-support-online/knowledge-base-articles.tec1247034.html

Hi Sumanth,

It is the OASIS standard that RelayState value to be limited to 80 bytes in length:

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-binding-simplesign-cd-04.html 

Are you observing following error in affwebserv.log:

[WARNING] Length of Relay state XXXXXXXXXXX is greater than 80 characters

Still the above error should not lead you to the error 404.

I see this error message when we access IDP initiated with relay state login URL in affwebserver.log. 

[WARNING][sm-FedClient-03070] Length of Relay state https://xxxxxxxxxxx--xxxxxxxxxxx.cs2.my.salesforce.com/setup/secur/RemoteAccessAuthorizationPage.apexp?display=popup is greater than 80 characters

I don't see this error message in affwebserver.log when we access SP initiated login URL.

Thanks,

Sumanth

Does CA SSO has any solution if relay state is more than 80 character length?

Reply from SFDC support.

OAuth with SAML 2.0 authentication, relayState may be longer than 80 char
https://help.salesforce.com/HTViewSolution?id=000214100&language=en_US

Hi Sumanth,

we don't have any problems if the relay state is more than 80 characters. we will just log the message but still process it. But SAML specification says it should not be more than 80 characters but we don't deny the request if it is more than 80 characters.

Thanks,

Sharan

Hi Sharana,

It's working in the case of IDP initiated, but not for SP initiated.

And also the message was logged only (affwebserver.log) in the case of IDP initiated work flow.

Do I need to turn on any trace to log the message in case of SP initiated work flow?

Thanks,

Sumanth

There was a query string limitation in IIS server (proxy server) by default it allows 2048 bytes.

I increased query string length to resolve the issue.

Thanks,

Sumanth