First of all, I am very new to the Salesforce platform. So apologies in advance if this is very straight forward and obvious.
So we are migrating our old app (based on .net platform) to Salesforce Community Cloud. One of the components in the app connects to the third party API service. The third party API endpoint uses Basic Authentication. We use service account credentials to generate basic authentication header.
We want to insert this component in a page using community builder. So whenever users visit the page, the component will pick the properties from logged in user, hit the third party API, get the required information and show on the page.
Is this doable in Salesforce? If yes, what is the best preferred way of achieving this?
Code-based approach - If your API is HTTP-based it's easy to implement in Salesforce via Apex callouts. The service account credentials should live in an instance of a Named Credential, it works together with a callout. Named Credential will automatically generate a Basic Auth header for you; this option in the Named Credential config screen is unhelpfully called "Password Authentication".
Declarative-ish approach: take a look at External Services:
With External Services, you use SF tools to import Swagger or
Interagent-based API definitions right into Salesforce using a schema.
Once you import the definitions, you can create a flow based on the
Apex classes generated from your External Services registration.
Related
I have web app written in react which is Single Page Application. Then I have back end API written in .NET core 3.1.
As I mentioned earlier I have web app written in react so this react web app has to call one more API to read some configs. This third application is also a API application written in .NET core 3.1. As soon as web app spins up, it will call this third APP and read configs like API URL of second application and other azure related details. Now this third API app should be protected. Only web app should access this app and not any other users.
So I am trying to find what are the best scenarios available in azure AD. Can someone help me to understand the possible scenarios to handle this?
What you seem to want to accomplish at the moment is for the web application to access the third API application. If this is the case, it is simple. The steps are as follows:
First, you need to expose the api of the third API application protected by Azure, which can be configured according to the following process
Azure portal>App registrations>Expose an API>Add a scope>Add a client application
Next, you need to define the manifest of api applications and grant application permissions to your client applications (this is the role permissions you define yourself, you can find it in My APIs when you add permissions). This is the process of defining the manifest.
This is to grant permissions for the client application (You can find your expose api permissions in My APIs.):
Finally, you need to obtain an access token using the client credential flow where no user is logged in:
Parse the token：
so as per you description It seems you want to permit only API application to access your third application.
One thing you can do you can create a user group and give acess to your API only and put application restricted to this group only.
See this hope it will help
https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/users-default-permissions
We have a SAAS model web application that is used to serve multiple customers. Few of these customers have their own SAML2.0 Identity Providers against which they want their users to get authenticated.
How can I create a service provider for my web application in which I can configure these multiple Identity providers and redirect the user to their respective login page based on the URL and redirect them back after successful authentication?
Can someone please guide me on this. So far what I have done is install the Shibboleth service provider on each of my servers and use that one server to serve only 1 customer who requires Authentication using their Identity provider, but this will not work with SAAS based model application.
Varun
What you're looking for is something known as a discovery service. This enables the user to select the identity provider appropriate for them so that the SP can send them there to authenticate.
There's a page on the Shibboleth wiki describing this concept: IDPDiscovery
The Shibboleth SP ships with a discovery service known as the EDS that you can deploy locally: EDS
You could also build one as a static web page, or use a central discovery service provided by someone else if, for example, you're part of a federation that provides one.
We have a SharePoint publishing site with anonymous access hosted on internet. As per the latest requirements, we need to implement user login (AzureAD, Microsoft personal and work accounts, and more) for some pages within the portal.
There are two approaches we have come up with:
Using msal.js file. Implementing login of user at client side itself and calling Partner Center Web API with user token to check the validity of the user plus performing required operations.
Create a Web API with with Microsoft.Owin.Security.OpenIdConnect nuget package at Web API end to implement login and also use it for doing out required operation of retrieving and modifying data from the backend.
Which approach may work best in our scenario?
Is there any other way to achieve this?
The difference between these two approaches is that they are using the different flows to integrate with the identity data provider.
The second approach that using the server-side code is using the authorization code grant flow which is a stand flow to interact with identity data provider.
The first approach that using the msal.js is using the implicit flow. is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript. In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly.
More detail the flows using the OAuth 2.0 are defined in the OAuth 2.0 Authorization Framework.
(intro)
I am new to Google Cloud Endpoints and I have started to build some HTTP REST services.
The purpose of those services is to be consumed directly by the users of my application (Business to Consumer - not business to business).
(The question)
I need to secure my services in a way to have only registered users being able to retrieve sensible data (and after login). My main purpose is to have the list of registered users saved in my database on CloudSQL (Dont want to use FB of Google Accounts). I was not able to find particular information about this point in the official Google documentation regarding authentication.
Can anyone advise me of the way to proceed and suggest some tutorials?
Thank you in advance.
The Endpoints proxy can validate JWTs, and we provide a couple of alternatives for creating those. Both Auth0 and Firebase have good user management capabilities and client-side libraries for generating JWTs. Both allow you to choose an identity provider (like FB or Google) or simply use username/password.
Check out the documentation here.
If you don't want to use Auth0 or Firebase Authentication, you can sign JWTs yourself with a private key and just give the proxy the URL of the Public Key (see the "Custom" tab on that same documentation page).
As far as looking up individual users in the database, you would have to do that part on your own.
I'm pretty new to SalesForce and their Apex language. I've been reading some documentation and tried the integration between Google and SalesForce.
I'm wondering is it possible to emulate an auth token from google to SalesForce?
I'm trying to read a google spreadsheet and then fill up a SalesForce object automatically. The user login will always be the same/universal for this spreadsheet, so I have the credentials required to login.
I am working off of the sample that requires a visualforce, and I'm wondering how would I automatically do the session id token that the google spreadsheet API requires.
Any ideas?
The old-school, hard way would be to send a login() call to the API (available through SOAP messages). Salesforce API is well documented and plenty of examples are available (both in programming languages and for raw XML requests/responses).
But I have no idea what possibilities you have from Google side, if it's only JavaScript then you might not be able to send and retrieve AJAX-like calls to another domain...
Recently another option emerged and that is REST API (no SOAP needed). Looks more promising and easier in my opinion. Quick intro is available here and you'll find more documentation on the bottom of the page.
Last but not least - 2 interesting links:
http://code.google.com/apis/gdata/articles/salesforce.html for some integration tutorial
and built-in integration offered by Salesforce: http://www.salesforce.com/assets/pdf/datasheets/SalesforceGoogleApps.pdf
I've used custom settings to do this. Use OAuth to get a token for Google, then store that token in Salesforce custom settings (Setup-Develop-Custom Settings). You can then retrieve the token for callouts to Google from that custom setting for any user needing access to Google Apps. The downside is, every user will authenticate as your custom setting token user. The upside is that they won't need to individually authenticate. Custom settings are retrievable via Apex using a simple getter, and live as Apex-like objects.
Also keep in mind, Google requires each service to use it's own token. So, if your user wants to use Calendars and Spreadsheets, that's two separate tokens that will need to be stored and retrieved for the callout.
I generally allow users to create their own authenticated session tokens via OAuth if they want to do that, then failover to the custom settings to get the general admin token if necessary.
Are you trying to log into Google Apps from SFDC? There are options for Google Apps within Salesforce, go to Setup > Administration Setup > Google Apps > Settings. I've not used this and it requires some setup, but thought I'd point it out. Aside from that I can only blurt out OAuth (getting users to authenticate with Google from within Salesforce when trying to access Google Apps) and SSO (which I know can be used to authenticate from an external system, though not sure if it works the other way).
Look into the "Named Credentials" menu in salesforce setup.
There, you can store auth credentials for the services accessed via Apex:
"A named credential specifies a callout endpoint and its required authentication parameters. When setting up callouts, avoid setting authentication parameters for each callout by referencing named credentials."
a username/pass combo can be used, or a certificate, or an AWS signature, and there is a JWT option..
Help docs: https://help.salesforce.com/articleView?id=named_credentials_about.htm&type=5