2

I have created Auth. Provider for Google and LinkedIn. We want community user to login/register via Google or LinkedIn. It is working correctly for community users but from community URL internal user can't able to login. we are getting this exception "NO_ACCESS: User was an internal user for the community". In Community setting we already allow internal users to login and System Adminimstrator profile is added in Members.

For checking Internal Users we added Gmail and Linkedin In My Domain. we found below strange cases: 1. Internal user can login via username and password as well as gmail and linked but only from my domain url. 2. Internal user can login via username and password to community. 3. Internal user can’t login to community via LinkedIn or Gmail.

2
  • Hey Sunil - I believe I saw your other post on the developer forum. I'm having the same issue, however I can confirm it's working on SAML. Any idea of this is specifically for OIDC?
    – zainogj
    Dec 19, 2017 at 22:43
  • Hi Sunil, did u find any solution for this ?
    – sf_user
    Feb 18, 2018 at 23:56

1 Answer 1

3

It's a bit of a hack, but it's an answer...

I got around the issue by leveraging the startURL parameter. The Authentication Provider endpoints all support a series of parameters to assist in directing the user to where they need to go. Specifically the startURL parameter allows you to direct the user to a specific path within the app.

It's possible to direct the user to an apex page which redirects the user to the community. For instance, I've appended startURL=apex/app to the endpoint. When I hit the endpoint, I login, then I'm directed to my domain/apex/app which re-directs to the community domain.

The downsides to this:

  • I don't see how to append the startURL parameter to the native Salesforce community login page. Therefore, you may need to provide a separate endpoint to redirect users specifically to the authentication provider which more or less defeats the purpose of allowing them to select how they want to login.
  • Personally, I don't like the idea of bouncing the user around once they are in the app.

I do plan on using this as these are internal users and we are ok sacrificing some experience in order for it to work and we only support a single authentication provider. It still baffles me that Salesforce support internal users logging into a community via SAML but not OIDC, but as long as it's acknowledged as an idea to implement then there's progress.


Edit 1: providing clarity on URLs and process

Salesforce Documentation on Google Auth Provider configuration

Salesforce Domain URL: https://login.salesforce.com/services/auth/sso/{{org-id}}/{{auth provider API name}}
You may want a different auth provider URL. I am showing the SSO URL here; these can be found in your Auth provider setup page in Salesforce. The domain will change when myDomain is enabled as well.

Login URL: https://{{id-provider domain}}/auth
This can vary by id-provider.

Callback URL: https://login.salesforce.com/services/authcallback/{{org-id}}/{{auth provider API name}}
Same as above, domain may change if myDomain is enabled.

  1. User goes to Salesforce domain URL with startURL parameter appended.
  2. Depending on domain configuration, user is presented login page with all possible authentication providers available.
  3. User selects the auth provider they want to use to login; if domain is configured for a single auth provider, Salesforce will redirect the user to that auth provider login url at step 2. In this step, the startURL is passed through to the login URL as the RelayState parameter.
  4. User authenticates successfully and is directed back to callbackURI with the startURL parameter.
  5. User is authenticated and directed to the path referenced in the startURL.

For example: I want to login and land on the native reports page. My login URL would be https://login.salesforce.com/services/auth/sso/{{org-id}}/{{auth provider api name}}?startURL=00O/o

6
  • Hi I am trying to use google as identity provider to log my users in community and get similar error. I changed the redirect_uri in google credentials page and added starturl as you mentioned to redirect to specify page but when i now try use SSO URL, I am getting redirect_uri mismatch. Can you please suggest. Thanks
    – sf_user
    Feb 18, 2018 at 23:55
  • 1
    Hey sf_user - it sounds like you've put the startURL on the wrong URL. The redirect URI should remain the same as you had it before - which is why you are seeing the redirect URI error. The redirectURI should be whatever Salesforce is providing as the callback URL. I've expanded on the answer to better define the different URLs as well as how Salesforce passes the startURL parameter between them.
    – zainogj
    Feb 20, 2018 at 17:35
  • Thanks zainogj for explanation. It is clear now. I will give a try.
    – sf_user
    Feb 20, 2018 at 17:48
  • 1
    Unfortunately, I've not been able to determine that. I posted here a couple month back with no answer - I think I posted on dev forums as well with no luck. From what I've seen, Salesforce determines a state and expects that exact state back after authentication. I have not been able to decode it to see what it contains either. Our registration process requires a parameter passed into the State, but I had to create a work around to solve for it.
    – zainogj
    Feb 20, 2018 at 18:25
  • 1
    It's the answer to my linked post in my previous comment. Essentially, I still passed the state to the registration page. Upon registering, the user received an error parameter. I defined the error URL of my community to point to my Salesforce domain and setup a redirect to send them to the correct location. The trick here was that they were authenticated even with the error parameter. For that to work for you, the error URL would need to be a VF page that parses the parameter and redirects to the correct location... bit of a stretch but might work.
    – zainogj
    Feb 20, 2018 at 18:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .