Hi,

 for SAML 1.1 it is necessary for the Idp (Identity Provider) to communicate with the SP (Service Provider); SF docs also mention that the Idp should be on a public domain (not just IP).

However, for SAML 2 which is SP first (SP = Sales Force / SF) in this case, I wanted to have a localhost implementation of SSO server + SAML. Is it practical to consider this testing scenario since all requests are routed through the browser as per SAML 2.0 afaik.

Someone please share some light on this... am having a tough time setting up to test this stuff out.

Hi there,

In testing out Salesforce.com as an IdP, I'm running into what looks like a violation of the SAML 2.0 spec.

IdP initiated (unsolicited) login to my SP works fine.

SP initiated login is where I'm having issues.  In this case, the SubjectConfirmation returned by Salesforce.com looks as follows:

<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml:SubjectConfirmationData NotOnOrAfter="2010-11-22T05:42:09.711Z" Recipient="http://<mysp>/Saml/SP/SSO/Post"/></saml:SubjectConfirmation>

Unfortunately, this is lacking an "InResponseTo" attribute.  The SAML 2.0 Web Browser SSO Profile (629-635) states the following:

At lease one bearer    <SubjectConfirmation>    element MUST contain a    
<SubjectConfirmationData> element that itself MUST contain a Recipient attribute containing
the service provider's assertion consumer service URL and a NotOnOrAfter attribute that limits the
window during which the assertion can be [E52]confirmed by the relying party. It MAY also contain an
Address attribute limiting the client address from which the assertion can be delivered. It MUST NOT
contain a NotBefore attribute. If the containing message is in response to an <AuthnRequest>,
then the InResponseTo attribute MUST match the request's ID.

Bug?

Thanks,

Scott

I'm running into an error when trying to authenticate to salesforce using SAML (my localhost app is the identity provider, salesforce is the Service Provider). In the SAML validator tool I get:



Signature or certificate problems       

The signature in the response is not valid       

The certificate I'm using is one that I just created locally using IIS - it validates fine if I use the SignedXML class in .Net, but Salesforce is having issues with it. Does the certificate have to be signed by a trusted authority to use with Salesforce? If not then has anyone got any ideas what I can try?

thanks

I'm developing an app which utilizes OAuth 2.0, and it appears that there is a bug in the implementation.

I'm using Google's "oauth2client" library for python, and kept getting a "scope parameter not supported" error when trying to exchange an authorization code for an access token (using the web server flow).  The library sends the scope parameter during both the initial step of the flow, as well as with the exchange step.  However, it appears that SalesForce throws an error if a scope parameter is included with the exchange request - but it will work if the scope param is included but is the empty string.

Section 3.3 of the OAuth 2.0 RFC states "The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter." - which leads to the conclusion that this is an implementation bug.  

The current situation leaves me with making changes to a third-party library (not ideal), or not being able to specify a scope (not ideal, as I must then use the default).

Is it possible to use SAML single sign on for only certain profiles?

If so, How?

Hello,

- The SSO Implementation Guide says that when defining the start page when using SAML 2.0, the start page is  "the page
the user attempted to access before they were authenticated. The SAML 2.0 start page must support Sp-init single sign-on."

How do we make the start page support Sp-Init SSO?

- In the same place it is also said that  "If you are using SAML 2.0, you can also use the RelayState parameter to control
where users get redirected after a successful login."

How may we enable the use of RelayState? Where should we define it?

Thanks,

Haim

Hi,

 for SAML 1.1 it is necessary for the Idp (Identity Provider) to communicate with the SP (Service Provider); SF docs also mention that the Idp should be on a public domain (not just IP).

However, for SAML 2 which is SP first (SP = Sales Force / SF) in this case, I wanted to have a localhost implementation of SSO server + SAML. Is it practical to consider this testing scenario since all requests are routed through the browser as per SAML 2.0 afaik.

Someone please share some light on this... am having a tough time setting up to test this stuff out.

Hello,

I am evaluating PingFederate 6.4 as a Idp and configured to work with backbend LDAP.

I have created self -signed certificate with PingFederate and uploaded to SalesForce.com during SAML 2.0 enable configuration.

When Idp initiates SSO flow, I I can see in logs that login was successful but I am getting following error after redirection which indicates that there is mismatch between certificate. I have uploaded correct certificate to SalesForce.com which was generated by PingFederate server..

================== Error message

Your login attempt using single sign-on with an identity provider certificate has failed. Please contact your salesforce.com administrator for more information.

==========================

Did I miss anything ? Is this correct interpretation of error message ?

Thanks in advance.

Raj

We're having an issue with using Shibboleth as our IDP.    Salesforce is rejectig the Shibboleth SAML assertion because of the presence of the inResponseTo attribute.   Our ITS group won't modify Shibboleth to not send the attribute because that will break other implmentations.  Any Shibboleth users out there with some insight?

Issue: Salesforce rejects the SAML assertion from Shibboleth because of the presence of an attribute called InResponseTo

Taken from Shibboleth users forum http://shibboleth.1660669.n2.nabble.com/IdP-Initiated-SSO-td5741045.html, posting by Brent Putman on 01/25/2011

Many people, including our school, have gotten the Shib IdP to work via
SAML 2 with salesforce.com.  The only real substantive issue is that the
issued Response and Assertion must have the InResponseTo attribute
removed, else they are rejected by Salesforce.  That requires some mods
to the IdP, either code changes or additions.  See the list archive for
some solutions people have come up with.

Taken from Shibboleth users forum http://shibboleth.1660669.n2.nabble.com/IdP-Initiated-SSO-td5741045.html, posting by Scott Cantor on 01/26/2011

That [commenting out the code in  the IdP that sends out a inResponseTo attribute in the SAML response] will simply break other SPs ... that enforce the check. In other words, this is a bad idea.

Previous Salesforce response to Salesforce not sending out the inResponseTo, taken from Developer Force forum postings at http://boards.developerforce.com/t5/Security/Salesforce-com-SAML-IdP-Problem/td-p/218531, posting from Chuck Mortimore at 11/23/2010

 That being said there seem to be enough implementations that favor duplication of the inResponseTo that we need to fix it.   Code wins as they say.

Is it possible for Salesforce to look at adding the inResponseTo attribute?

HI,  I am very confused..

We are using code to communicate via SAML with Salesforce.

We are trying to be a ldP and I am confused on;

1. Do I create the Cert / Keys from Salesforce?  if Not then I use a CA to create, fine.

2. What is the FQDN or just domain name that should be used?  x.salesforces.com ??  or my domain?

3. Do I upload the Cert or Private key to Salesforce?  Then I will understand what I need on myside.

Thank you for help/understanding.  These simple questions don't seem to be clear to me anywhere.

What are his profiles and roles when a user reaches another site via SSO ?

#Senario1  SalesForce serves as IdP.  

      How can the service provider know this guy's profile and role? 

#Senario2  SalesForce serves as SP

      How can SalesForce decide this guy's profile or role?  

Hi there

I am trying to setup a new service provider for our Salesforce organisation.  I have setup our salesforce domain and have been given the webservice URL from the SP to add into the ACS section of the service provider config.

The problem at the moment is that we are not seeing any traffic between Salesforce and the SP when I use the Idp initiated URL.  All that happens is that we get a "web page not found" error and an Error 6 (net: ERR_FILE_NOT_FOUND) message.

Currently the SP has only setup a webservice to listen for incoming communication so that they can create their own SAML response so I wonder if there is something else that may need configured on their end before we can send messages over?

Any advice would be great.

Hi there,

In testing out Salesforce.com as an IdP, I'm running into what looks like a violation of the SAML 2.0 spec.

IdP initiated (unsolicited) login to my SP works fine.

SP initiated login is where I'm having issues.  In this case, the SubjectConfirmation returned by Salesforce.com looks as follows:

<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml:SubjectConfirmationData NotOnOrAfter="2010-11-22T05:42:09.711Z" Recipient="http://<mysp>/Saml/SP/SSO/Post"/></saml:SubjectConfirmation>

Unfortunately, this is lacking an "InResponseTo" attribute.  The SAML 2.0 Web Browser SSO Profile (629-635) states the following:

At lease one bearer    <SubjectConfirmation>    element MUST contain a    
<SubjectConfirmationData> element that itself MUST contain a Recipient attribute containing
the service provider's assertion consumer service URL and a NotOnOrAfter attribute that limits the
window during which the assertion can be [E52]confirmed by the relying party. It MAY also contain an
Address attribute limiting the client address from which the assertion can be delivered. It MUST NOT
contain a NotBefore attribute. If the containing message is in response to an <AuthnRequest>,
then the InResponseTo attribute MUST match the request's ID.

Bug?

Thanks,

Scott