Hi folks,
I am looking at the possibility of using Sales force as an external IDP for one of our clients.  The problem is that while I am trying to mock out an example service I cannot set up my trial salesforce account to use IDP.  

In the document here: https://help.salesforce.com/apex/HTViewHelpDoc?id=identity_provider_enable.htm&language=en_US (https://help.salesforce.com/apex/HTViewHelpDoc?id=identity_provider_enable.htm&language=en_US) it states that you can just click on a menu link (Security Controls -> Identity Provider)  to enable SalesForce as an identity provider.  I have created a domain as one other document says but the problem is that I don't have that link:



I only have the trial account at this time as I'm evaluating the process etc. but do I need to have fully paid access to see this functionality, even for a trail?
Thanks for any replies to this strange problem.

We have some APEX code in a Salesforce application that makes a callout to an external service we've developed.  We already have clients consuming the external service without issue from outside of Salesforce (via .NET, Java, PHP, etc.). 

 

Our testing in Salesforce, however, has shown that the callouts fail when they are made to our external service due to a certificate issue.  

 

System.CalloutException: IO Exception: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

 

Based on what we are seeing, the issue appears to be related to the certificate chain for our certificate.  Our certificate was issued by Network Solutions and we've found that they (essentially) provide two alternate certificate paths:

 

/C=US /O=Network Solutions L.L.C. /CN=Network Solutions Certificate Authority
    >> /C=US /O=Network Solutions L.L.C. /CN=Network Solutions EV Server CA
        >> /C=US /O=[Our Company] /OU=IT /OU=Secure Link EV SSL /CN=[Our Domain]

 

and

 

/C=SE /O=AddTrust AB /OU=AddTrust External TTP Network /CN=AddTrust External CA Root
    >> /C=US /O=Network Solutions L.L.C. /CN=Network Solutions Certificate Authority
        >> /C=US /O=Network Solutions L.L.C. /CN=Network Solutions EV Server CA
            >> /C=US /O=[Our Company] /OU=IT /OU=Secure Link EV SSL /CN=[Our Domain]

 

What we've found is that the "Network Solutions Certificate Authority" certificate root in the first chain I posted has the same keys as the second certificate in the second chain I posted (which shares a CN, etc.).  Given their matching signatures, they are both treated as valid signers of the "Network Solutions EV Server CA" certificate.

 

From what we've been able to determine, the first (shorter) chain represents the newer chain being used by Network Solutions and the alternate chain is there to maintain some sort of compatibility.  

 

The issue seems to be that Salesforce recognizes the AddTrust root certificate (present in the secondary longer chain), but not the Network Solutions root certificate for some reason.  Both roots are installed on the servers hosting our external service, but the chain the servers respond with is the first chain not the one containing the "AddTrust" root.  The result is that Salesforce doesn't recognize the validity of our certificate even though it is in fact a valid certificate.  

 

Based on these findings, it seems like the issue is that Salesforce does not include trust for the Network Solutions Certificate Authority root certificate?  Is this an oversight or is there an explicit reason for this behavior?

 

We can't make changes to the certificate behavior on our external servers without impacting our non-Salesforce client usage of our service, so we need to determine how to get this working with Salesforce.  Any assistance that can be provided would be greatly appreciated as this is client-affecting.

 

I've been a Force.com developer for 7 years and I can't for the life of me figure this out!

 

The docs allude to what this post says directly: that to add a Remote Access Application to a Managed Package, you have to do so during creation of the managed package.

 

However I can find no way to do so.  In the flow of the managed package creation I see this when first making the package:

 

 

Hmm, nothing here.  Maybe after I save it?

 

 

Not here either.  No new button under Remote Access.  Maybe if I edit the package?

 

A few new options here, but nothing regarding a remote access.

 

So maybe if I kill the managed package and make a new Remote Access?

 

 

Not seeing anything here to add to a package, maybe after I save it?

 

 

ARGH!

 

So how exactly can I add this Remote Access Application to my package?  Does anybody know?  Thanks.

 

The specifications (https://na1.salesforce.com/help/doc/en/remoteaccess_oauth_SAML_bearer_flow.htm) for the OAuth 2.0 SAML Bearer Assertion Flow state that the Subject of the assertion must match the Username of the desired Salesforce user.  This is working well for us, but soon we will need to be able to create an assertion which matches the Federation Id of the desired user.

 

Does the OAuth 2.0 SAML Bearer Assertion Flow support Federation Id?  If not, is there a workaround possible?

When going to Setup->Develop->Remote Access

 

The Callback URL field will not allow me to store a URL whose protocol contains a hyphen. If I attempt to do this it produces an error and does not validate.

 

I discussed the issue briefly with a mobile developer from Salesforce at Dreamforce and he confirmed it sounded like a bug. I'd love to be able to use a hyphen in the protocol so that I can call files directly in my Chrome Extensions which will be really handy when authenticating via REST. Chrome requires a URL of chrome-extension://(ID of the Extension)/(Path to file). If I enter the URL without the hyphen it works fine and saves properly. With the hyphen I get the error message that the URL needs to be valid.

 

 

 

 

Hi,

I know similar questions on this have been asked before, but jus tin case someone has an answer.

I am making SOAP callouts from asynchrous code and it was all working fine until the certs expired on the server I was calling.

 

the certs were replaced, but now I get the following error:

Failed to loginSystem.CalloutException: IO Exception: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

 

Is it possible that Salesforce is caching the cert somewhere?

 

I tried deleting the remote site in the security controls and recreating it, but it made no difference.

 

The guy in charge of the server I am calling has come back with this:

I checked the following link: http://wiki.developerforce.com/index.php/Outbound_Messaging_SSL_CA_Certificates

Our certificate was signed by the following root certificate: COMODO High-Assurance Secure Server CA

Which in turn was signed by AddTrust External CA Root

This I can find in the list: http://wiki.developerforce.com/index.php/Outbound_Messaging_SSL_CA_Certificates#addtrustexternalca

 

The values seem to match, so the certificate should be recognised fine.

 

 

Hi,

 

We want to use delegated authentication so that mobile users can access Salesforce mobile apps without entering usernames and passwords. We're looking to use username and passwords (rather than username & token).

 

When using delegated auth for desktops, you can (for example) provide a link on an intranet page for users that will take the user to a page that passes the user's username and password to salesforce.com in a POST request. That user has a delegated auth enabled profile, so salesforce.com passes the credentials to a delegated authentication authority.

 

That part I'm clear on!

 

What I want to know is - how does this work for mobile application users? If a user downloads Salesforce.com Mobile they need to identify to the application what their username and password is. But if a user is SSO enabled, this will mean nothing to them.

 

So how does a user identify who they are? Is this method reliant on users entering their email address as their username (and therefore it is implicit that their username will be the same as their email address) and their network password as their salesforce.com password? Or does the mobile need to be routed through a proxy that will pick up the attempt to visit the login page and construct the necessary POST request instead?

 

Any input appreciated, especially from anyone with experience of doing this!

 

I'm using OAuth in an iPhone application using the standard iOS toolkit. If there is a scheduled maintence notification presented after login, the view is not optimised for the mobile screen. The user is presented with an almost completely white screen, and must scroll through to dismiss the message.

 

As far as I can see, there is no method for managing the window size on that notification. Is there a formatting option I'm missing? Any way to supress maintenance notifications in OAuth on a mobile device? Thanks.

 

Vincent

In reading  http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_om_outboundmessaging_setting_up.htm, in particular the section on Downloading the Salesforce.com Client Certificate, I was wondering if the certificate that is generated by that link is unique to each organization?

 

Or to put another way, if I'm developing an application that is to be installed by customers, how would I store a certificate that can be used to securely connect to our external server(s)?

 

Thanks,

Eddy

 

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>

 

 

Hi All,

Hi folks,
I am looking at the possibility of using Sales force as an external IDP for one of our clients.  The problem is that while I am trying to mock out an example service I cannot set up my trial salesforce account to use IDP.  

In the document here: https://help.salesforce.com/apex/HTViewHelpDoc?id=identity_provider_enable.htm&language=en_US (https://help.salesforce.com/apex/HTViewHelpDoc?id=identity_provider_enable.htm&language=en_US) it states that you can just click on a menu link (Security Controls -> Identity Provider)  to enable SalesForce as an identity provider.  I have created a domain as one other document says but the problem is that I don't have that link:



I only have the trial account at this time as I'm evaluating the process etc. but do I need to have fully paid access to see this functionality, even for a trail?
Thanks for any replies to this strange problem.

Hi,

 

I've implemented Salesforce OAuth 2.0 Web Server flow and it works perfectly well with a HTTP callback uri. But when I use an HTTPS callback URI, the page on which the User Approves the app to use Salesforce asks for less permissions than what is shown for HTTP URI. 

 

The Remote Access Applications setup for both is exactly the same except the callback uri's ( obviously )

 

The page requesting the user to grant access for HTTP callback uri is asking for 3 permissions ( see https://www.dropbox.com/s/62qzsgev3nidw9o/developersalesforce.tiff ) 

1. Access your basic information

2. Access and manage your data

3. Perform requests on your behalf at any time

 

While the same page for HTTPS callback uri is only asking the first two options and not the third one ( see https://www.dropbox.com/s/w0k92iu42wuudug/securesalesforce.tiff )

 

Because of this, I cannot refresh my access tokens and the request to refresh access token fails.

 

Any insights on this will be highly appreciated.

 

Regards,

Agraj

We have some APEX code in a Salesforce application that makes a callout to an external service we've developed.  We already have clients consuming the external service without issue from outside of Salesforce (via .NET, Java, PHP, etc.). 

 

Our testing in Salesforce, however, has shown that the callouts fail when they are made to our external service due to a certificate issue.  

 

System.CalloutException: IO Exception: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

 

Based on what we are seeing, the issue appears to be related to the certificate chain for our certificate.  Our certificate was issued by Network Solutions and we've found that they (essentially) provide two alternate certificate paths:

 

/C=US /O=Network Solutions L.L.C. /CN=Network Solutions Certificate Authority
    >> /C=US /O=Network Solutions L.L.C. /CN=Network Solutions EV Server CA
        >> /C=US /O=[Our Company] /OU=IT /OU=Secure Link EV SSL /CN=[Our Domain]

 

and

 

/C=SE /O=AddTrust AB /OU=AddTrust External TTP Network /CN=AddTrust External CA Root
    >> /C=US /O=Network Solutions L.L.C. /CN=Network Solutions Certificate Authority
        >> /C=US /O=Network Solutions L.L.C. /CN=Network Solutions EV Server CA
            >> /C=US /O=[Our Company] /OU=IT /OU=Secure Link EV SSL /CN=[Our Domain]

 

What we've found is that the "Network Solutions Certificate Authority" certificate root in the first chain I posted has the same keys as the second certificate in the second chain I posted (which shares a CN, etc.).  Given their matching signatures, they are both treated as valid signers of the "Network Solutions EV Server CA" certificate.

 

From what we've been able to determine, the first (shorter) chain represents the newer chain being used by Network Solutions and the alternate chain is there to maintain some sort of compatibility.  

 

The issue seems to be that Salesforce recognizes the AddTrust root certificate (present in the secondary longer chain), but not the Network Solutions root certificate for some reason.  Both roots are installed on the servers hosting our external service, but the chain the servers respond with is the first chain not the one containing the "AddTrust" root.  The result is that Salesforce doesn't recognize the validity of our certificate even though it is in fact a valid certificate.  

 

Based on these findings, it seems like the issue is that Salesforce does not include trust for the Network Solutions Certificate Authority root certificate?  Is this an oversight or is there an explicit reason for this behavior?

 

We can't make changes to the certificate behavior on our external servers without impacting our non-Salesforce client usage of our service, so we need to determine how to get this working with Salesforce.  Any assistance that can be provided would be greatly appreciated as this is client-affecting.

 

I need to change Users Password and let them have the same passowrd along with thier Windows Passcode ..

 

Hi,

 

I have a requirement to calculate commission for all sales guys based on their quota and their actual numbers.  However, commission is calculated based on their base salary.  Since commission, salary are very sensitive information, we want to really restrict access to salary, commission even to the System Admin folks.  We have about 6-7 people as System Admin across the globe.  I'm looking around, but cannot find any solution that even prevent System Admin people to see these sensitive data. 

 

Is there a way, or a feasible solution to implement a password-protected objects/fields that only allow those who have passwords to access to those sensitive information fields (salary/commission) ?  I know the nature is that System admin would be allow to access everything.  So, not sure as if I can add another layer of password protection to certain objects or certain fields.

 

Any thoughts would be approciated.

 

Ken

Hi All,

 

I got a certification from my Admin, Now where i can add the Certificate in Salesforce for accessing External Webservice..

Hello there,

 

I have a OAuth2 web flow. I set "immediate" to true when requesting the authroization code, in order to probe whether user is logged in and has already granted my access permission. But the callback always return "immediate_unsuccessful", even user is logged in and granted permission already.When I set the "immediate" back to "false", the flow went through without login prompting which proves everything else is working. One observation is if I install theassociated connected app, the problem is gone. I am confused cause my impression is connected app is only to provide client id and secret with some admin policy setting.

 

Anybody could educate me if there are any correlations between connected-app installation and immediate flag? Or there is some prerequisites to use "immediate" flag beyond the fact user has logged in and user has granted permission?

 

I am stuck in this issue for days, help greatly appreciated! 

 

jason

When configuring SAML 2.0 to use SP-Init I'm receiving the error message during token validation: Unable to parse the response: Invalid InResponseTo attribute in SubjectConfirmationData element.

 

I'm currently using a developer site with a normal configuration except that I've switched to REDIRECT instead of POST for binding.

 

The IdP receives the AuthRequest properly and generates a token from the AuthnRequest, and the InResponseTo value is being set from the AuthnRequest ID attribute.

 

Switching back to IdP-initiated auth works fine.

 

Here is the full validator output:

 

Last recorded SAML login failure:  2013-02-25T20:52:04.901Z

Unexpected Exceptions   Unable to parse the response: Invalid InResponseTo attribute in SubjectConfirmationData element

1. Validating the Status

  Unknown

2. Looking for an Authentication Statement

  Unknown  

3. Looking for a Conditions statement

  Unknown  

4. Checking that the timestamps in the assertion are valid

  Unknown

5. Checking that the Attribute namespace matches, if provided

  Unknown  

6. Miscellaneous format confirmations

  Unknown  

7. Confirming Issuer matches

  Unknown  

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

  Unknown  

9. Checking that the Audience matches, if provided

  Unknown

10. Checking the Recipient

  Unknown  

11. Validating the Signature

  Unknown  

12. Checking that the Site URL Attribute contains a valid site url, if provided

  Unknown

13. Looking for portal and organization id, if provided

  Unknown 

 

Curious things of note: SAML Validator shows that my org is using SAML v0.0 even though it's configured as 2.0

We have an external application which we would like to authenticate using salesforce.com. I have read salesforce.com documentation for using OAuth but i am not clear how to implement this feature (We do not want Client to manually go and create Client key). Basically we want someone to access our system but login authentication will be verified by salesforce. Imagine a website which authenticates by using Salesforce.com credentials. Any help is appreciated.

Hello,

I am trying to authenticate API calls from my application using the SAML Bearer Token flow and getting an HTTP 400 back with the message {"error":"invalid_grant","error_description":"invalid assertion"}.  As far as I can tell, my post meets all the requirements listed in the documentation, so I don't know if there is still a mistake in the SAML I am generating or a configuration issue, or what.  What is the best way for me to approach debugging this problem? Is there a tool similiar to the SAML validator that can be used with SAML assertions?  Or a log somewhere of why requests are being rejected?

 

Thanks in advance,

KS

HI All,

 

We are using Salesforce as IdP and we enabled also the Single Sign-on settings in Salesforce. Now we want to use Heroku and Play! to access Salesforce and the Play! application is the service provider.

 

This all works fine when using an internal salesforce user, but we want to use this functionality with a customer portal user but how can we manage that.

 

I found a doc where it states that we need to add the portal_id and the organization_id to the saml assertion but we only have a saml request and the saml assertion comes from the identity provider i think.

 

Help would be appreciated.

 

thx Sven

I have an application using oAuth for authorization. It's been working fine for months. Over the weekend, issues started happening and after digging into it, it appears that while the authorization is successful (response 200 with valid JSON object returned), we're no longer receiving a refresh token after authorization.

 

Here is the oAuth request/response:

REQUEST:
https://login.salesforce.com/services/oauth2/token?grant_type=authorization_code&client_id=[my_app_client_id]&client_secret=[my_app_client_secret]&redirect_uri=[my_app_redirect_url]&code=[the_auth_code_we_receive_during_authorization]

 

RESPONSE:

{

"id":"https://login.salesforce.com/id/00D30000000AAAAAAA/0053000000KKKKKK",
"issued_at":"1328965006241",
"scope":"full",
"instance_url":"https://[my_org].my.salesforce.com",
"signature":"J/YL4wUXF[stuff]ielR+GLrcBuDz/kHOJs3nKNs=",
"access_token":"00D30000000AAAA!AREAQHAQpw[stuff]ABL50MBOQVPsN.TTnrrvN2gAGNsrJHhK3ehSQvYU[stuff]MfqreLBp3eDXMnCNdJRl3"
}

 

This request is supposed to return a request_token parameter with the JSON response -- and it *always* has in the past. Docs here: http://wiki.developerforce.com/page/Digging_Deeper_into_OAuth_2.0_on_Force.com

I haven't had much luck getting SSO to work with my SAML assertion. Has anyone got this to work? If so, what does your saml response look like?  I signed my assertion and I believe everything is correct, yet the login history gives me "Failed: Assertion Invalid"

Any ideas?

Thank you.