I am trying to access the multiple communities in multiple salesforce sites with same connected-app but could not.
For example: I have created the two salesforce sites A and B. And created connected-app in A. To access rest API of A, i could authenticate with connected-app in A, But how to connect with B with using the same client_secret and client_id by differs in user_name and password?
Or is there any way to connect with REST API with username and password as creds?
Example: There is community_A1, community_A2 in Site A and community_B1 , community_B2 in Site B.
I need to access communities in both the Sites
This should work out of the box, what errors you're getting?
You can have 1 set of consumer key and secret and (if admin in target org didn't block it) you could use this to login to any SF in the world, sandbox or production, core SF or community.
Imagine being a developer of mobile app that pulls data from salesforce. You'd want to have just 1 pair of keys, not install separate key for every org people might install your app...
All org-specific stuff you need is username, password and login url. For community the login url will look like https://sandboxName-MyDomain.cs123.force.com/communityName
Once you have that, you can inspect all the OAuth2 stuff at https://sandboxName-MyDomain.cs123.force.com/communityName/.well-known/openid-configuration
Have you played with https://openidconnect.herokuapp.com/ ?
Paste your community url, for now keep the client and secret as is, click next. Login to community and keep clicking next. It should work fine and at the end - give you access_token / session id.
Now close this browser completely / open new incognito window and do it again. This time give your login url but also client and secret. Next, Next... Check the user's login history, it should mention your connected app now.
Now close this and do it last time, with the other community's login url and another user's credentials but still with your client and secret.
is there any way to connect with REST API with username and password
as creds?
Not for community. Internal users can get access in one go with https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_username_password_flow.htm&type=5 but community/experience users need this interactive login, there has to be a human consent / password typing step. And anyway it's not very secure flow. "Experience Cloud sites don’t support the OAuth 2.0 username-password flow."
In a pinch you could try the SOAP API's login method but from what I remember you may need to pass the community's Id in the message then
Connected-app is global metadata in salesforce. Once we create a connected-app in one org, then can access any salesforce site with the same client_id,client_secret, unless the admin has blocked the access.
I needed to add the custom profile into the community members to allow the access to the community via API (Community workspace -> administration -> members -> profiles.)
Related
I'm having the most bizarre problem, which I thought would be quite simple to fix. I helped a client set up a connection to the Amazon Selling Partner API by creating a private app in Seller Central:
Settings > User Permissions > Visit Developer Credentials
New app client
Get LWA credentials (client secret and client id)
Self authorize the app to obtain a refresh token
I've been using this successfully to pull Amazon SP API data for this client, but now the client wants to ensure we don't keep having access to their data and would like to either remove the app and create a new one or at least invalidate existing refresh tokens and/or client secrets and generate new ones. It's quite easy to create a new refresh token, but this doesn't invalidate the existing ones.
I've tried everything, including unticking all the boxes that grant you access to various scopes and putting in a random IAM ARN, but you have to leave at least one box ticked and the ARN has to match an existing one. Getting a non-technical client to create a new IAM ARN just for this doesn't make us look great, and I'm sure there has to be a way to revoke those credentials - what would happen if they became compromised for some reason?
I have a little bit of problem with the authentication on Sitecore website. Basically there is a button on the navbar, and when user clicks on the button, it redirects the same user to Salesforce to log in (Implementation of SSO). Basically I am using Salesforce as a identity provider and Sitecore Website as a service provider. Now I have a question? When user is logged, how can I get the ID of that user.
Do users in Sitecore User Manager have the same ID as the users in Salesforce, or I can just get a email to identify the user?
P.S: Sorry if this is a really stupid question, but I am a begineer when it comes to making Sitecore websites and the SAML SSO. Thank you in advance
Stop with the Sitecore and Salesforce for a second, you'll need to cover some basics and click through the login process manually before you automate it.
You probably are using a "connected app" in Salesforce that includes OAuth2 config (consumer key also known as client id; a secret; a list of scopes telling what this app is allowed to do on behalf of this SF user; a list of allowed urls that can login using this consumer key and secret. Etc.) It might even have something about Canvas Apps at bottom of the page.
Next would be - who's logging in. A core Salesforce user or do you have Partner Community, Customer Community (recently rebranded to "Digital Experiences").
Open incognito window and go to https://openidconnect.herokuapp.com/
For login host leave as is if you have production user or test.salesforce.com if you go from sandbox (you can also use branded urls, mycompany--dev.my.salesforce.com etc). If you have a community user you'll have to change the url to whatever is the community base url, like https://dev-mycompany.cs123.force.com/mycommunity
Don't change anything else, click next, next, next. This will take you through OAuth2 "web server flow" (one of many ways to log in). You type the username/password to SF screen and go back to that herokuapp with "authorisation code". The app has few minutes to swap that code for actual final "access token" and couple other pieces of info. Final step in this wizard calls OpenId "userinfo" - returning some info about the user that logged in. That's where you could pull the email if needed (and if there are extra fields you'd like SF to return in this process that's configurable too)
Close that browser window. Check the "connected app" in SF. Open new incognito window, do same thing but this time put your url, consumer key and secret (you might have to edit the app in SF first to allow callbacks to https://openidconnect.herokuapp.com/callback).
So now you should have rough idea about whole login process. Your sitecore app probably does same thing, receives authorisation code and exchanges it for final token. At that point you have valid SF session ID you could use to call that "userinfo", run queries (if the app allowes API access, check the "scopes") etc.
I doubt the Sitecore developer created it all by hand, you probably have some Spring stuff like spring.security.oauth2.client... My Java days are long gone but if you get better at manual click-click-click through the flow you should be able to follow existing code?
It's a big topic and there are other ways to do it (other OAuth flows, sending info about the current user when you have external page embedded in SF as iframe, you'd need to read about "canvas apps")... but that's best guess based on info you provided. You might want to check some trailhead courses too like https://trailhead.salesforce.com/content/learn/projects/build-a-connected-app-for-api-integration/implement-the-oauth-20-web-server-authentication-flow
https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_oauth_and_connected_apps.htm
https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/code_sample_auth_oauth.htm (Java but very hand-crafted raw HTTP, probably that Spring security is better)
I am working on a integration with Salesforce using REST APIs and, as part of the project, I need to send updates to Salesforce and these updates are not user triggered, they are system triggered.
Because of that, what I expect to see on Salesforce Field History is not a user name but the name of our Connected App (the app that made the update).
What I see today is the user name because the way the integration was made initially using OAuth Authorization Code flow.
To change that part of the project, I followed the link (OAuth 2.0 JWT Bearer Flow for Server-to-Server Integration): https://help.salesforce.com/articleView?id=sf.remoteaccess_oauth_flows.htm&type=5
Making that, I was expeting to generate a token for a System, not for a User, but that's not what happened: when I used the token generate from the JWT Bearer Flow and ran the update, the Field History still shows the user name.
What could I do then?
Which are the options in Salesforce to achieve the behavior I'm expecting?
The most important, in my opinion, is to have a Token for our system, not for a user.
Thanks!
Everybody is an user in Salesforce. Even if you access unauthenticated pages (some contact us form? case or lead capture) - it gets tracked under special Guest User.
It sounds stupid but gives you unified interface to control permissions (Profiles/Permission sets). You want guests to access only FAQ articles and make cases? Sure thing, do it in profile, don't get paranoid about people trying to guess right URLs. You think an app was hacked? You can terminate the session just like any other "user". Want to allow login only in certain hours and from certain IP? Sure.
An app connecting with JWT will still need username (main difference being it's "just" certificate for signing the request instead of password).
Your best bet is to create dedicated "Mr System", "SystemX integration" account. It sounds like waste of license but in the long run saves you questions "why did you edit my account at 1 am" and you could even use it as backup account if you use SSO and it ever fails...
I have a website named satellite.com built by AngularJS+NodeJS+MongoDB, it has an authentication system by ID & password, or third-parties like Google, GitHub. It already has many user accounts.
Now, I want to build a new website named umbrella.com, its authentication system and its database by ReactJS+NodeJS+MongoDB. Umbrella.com will include the functionalities of satellite.com (which will ideally share code with satellite.com) and some other functionalities. In the future, I want both satellite.com and umbrella.com to exist and work (though satellite.com may systematically redirect to umbrella.com/satellite/).
I wonder how umbrella.com can use the existing user accounts of satellite.com. Ideally, I hope
existing users of satellite.com could sign in umbrella.com with their old credentials, and have access to their data of satellite.com
new users could sign up on satellite.com, which will be valid to umbrella.com too
new users could sign up on umbrella.com, which will be valid to satellite.com too
I have total control of the two websites. Does anyone have a clear suggestion on how to structure and share the authentication system and the database of these 2 websites?
Edit 1: one issue is that when I set up Google Authentication for satellite.com, I remember that the domain name (i.e., satellite.com) was required. So now, can we use these authentications for another domain name (i.e., umbrella.com)?
If you are not using third party authentication like Google Auth or something where you have to specifically register your domain you can achieve that by following steps:
You can keep one database structure for both website with different
front-end. For that you user can login to both websites using same
credentials.
You can also go with one backend (Node server) for both the websites
as its seems like both are same and having same functionality.
Front-end can be different.
I've a scenario for a Third Party Client App (Mobile App - With Client Secret) to connect to the Identity Server for getting access to a Resource Server. During the user login the Client App display multiple store location for the user to sign in.
The Client App is designed to have a unique secret for each store location and one Client_ID.
When a store is selected by the end user for login - the ID Server gets a request from the client app with the Client_ID and the specific secret matching to the store location.
The Question I've over here is, how to make the Identity Server (3 or 4) to perform the User Login based on the Store Location.
I'm thinking of intercepting the Client_Secret to use it during the User Login to map to the correct store id by having a lookup table in place.
Is this a good approach to get this scenario worked out, or can someone shed some light with any possible suggestions to make this scenario work with the Identity Server.
The Expected flow:
Client App Displays the Store Location's in the Login Screen
User Selects the specific store location
User is directed to the Identity Server Authorization Endpoint and Client Validation is taken place.
Authorization Server Displays - User Login Screen
The Authorization Server authenticates the end User based on the store location. (Need to figure out a way to achieve this)
If you intend the login flow to be completed within mobile app itself and not within browser client, then you will need to use resource owner credentials grant type, in which case, it doesn't really matter if you have one or many secrets per store as it authenticates a single client based on your scenario.
On the other hand, if you intend the login flow to be completed within browser client, then it also doesn't matter if you have many secrets or one because in that case I assume the store selection would be done within the login screen like you mentioned which would part of the auth server.
All in all, nowhere in your flow the store location seem to matter unless there is some kind linkage between user credentials and store id. If that is the case, then this is essentially a multitenancy question for Identity Server 4 for which there are discussions already open with suggestions.
https://github.com/IdentityServer/IdentityServer4/issues/2673
How should you secure a multi-tenant API with Identity Server?