You will manage the roles in MC. Users still need to be created in Marketing Cloud, and have roles and business units assigned. The advantage of SSO is, that they would not need to provide MC credentials when logging into MC.
You can select which users in SFMC would be applicable for SSO, as you still might have cases where some users (e.g. if you are ...
In general, for oauth to work, the user needs to authorise salesforce to perform requests on their behalf.
If you haven't done it already, I suggest you go through the documentation on the many different types of oauth flows, and see if one of them fits your scenario.
You can create a Site and add a redirect from a Site URL to a destination. The destination can be any relative or absolute URL, including a MyDomain URL.
Out of the box, the hostname of the site will be auto-generated and added to a DNS for you by Salesforce. You have an option of using your own, custom domain controlled by your own DNS instead of having ...
The ConnectedAppPlugin is exactly the right place for logic like that. It's the only piece of code that's called during the SSO flow.
A Login Flow comes to mind as another option, but unfortunately it cannot detect which connected app started it.
The method you can use depends on the settings of your Connected App. If you set it to self-authorize, then you'd ...
Yes, that’s possible.
You can use Salesforce as an identity provider for single sign-on access to Marketing Cloud and access Marketing Cloud from a Marketing Cloud tab in Sales or Service Cloud.
To enable the single sign-on authentication and key management features for your account before performing this configuration, contact your Marketing Cloud account ...
As per Salesforce documentation:
Request Signing Certificate: The certificate used to generate the signature on a SAML request to the identity provider. This signing certificate is used when Salesforce is the service provider for a service provider-initiated SAML login. You save the signing certificate from the Certificate and Key Management Set up page.
You can only use one value for the Federated ID. The login ID that was provided to the authentication server does not need to be the ID that is presented to Salesforce. Most systems have a concept of a UUID or GUID that identifies the user logging in uniquely, no matter which login method they use.
The trick here is that you simply need to configure that ...
Salesforce can't enforce password policies for Federated Authentication, because it never sees the password (or even the username!) of the user being authenticated. The authentication is handled entirely by the authentication server, which then provides Salesforce with a unique identifier for that user (the Federation ID) along with a signature that proves ...
You are basically correct. If a user is using SSO, the third-party server is authenticating the user. No password is necessary if they will not be logging in directly to Salesforce. This is true for Delegated Authentication as well as SSO via SAML or another authentication method.
Yes. You can configure multiple Identity Providers in the same Org and let Users choose which IdP to use when they login. There is no restriction to be able to configure multiple IdPs in an Org.
I have had a similar use case where Users were located in different continents and the IdP was specific to a particular continent. So we went ahead and configured ...
You can control this scenario by leveraging the Okta auth provider that you've already configured as well as enabling (but not needing to set up) Delegated Authentication.
Per the help article on the topic:
SSO Login Settings Tips
When you configure users with an authentication ...
With Delegated Authentication, the user logs in through the normal Salesforce login page, but Salesforce checks with a third-party server for the password. In this case, the user literally has no Salesforce password and cannot log in without the authentication server's permission.
Delegated Authentication Flow
User -----> Salesforce Login
This is an error from Google. Please read Salesforce cloud application and follow all of the steps. This includes "installing" and "activating" an app in Google in order to allow access. Unfortunately, we will likely not be able to help you with this error, as the problem is within your Google configuration, not Salesforce.
With SAML, your community A will be ...
Here are the steps to enable communities as IDP, note it is very similar to the regular salesforce as IDP .
Create a my domain for your organization. It is under the Domain Management in set up
Under Security control find Identify Provider tab and click "Enable Identity Provider" for the org.
Create a connected app with "Enable SAML" checkbox checked. ...
The only way I can think to accomplish this, and I have no way of guaranteeing this will work, is to:
Configure the URL to point directly to SecureAuth login url
Configure SecureAuth to redirect to your community whether or not they are currently logged in (bypass login screen at this stage)
Configure the login link to push back to SecureAuth, maybe to a ...
So this, according to the documentation, is not an option for SSO sessions, though it is for other session types as found here:
When attempting https://mydomain.my.salesforce.com/?login, the user's profile (or permission set) has Is Single Signon Enabled = true
If you have somehow done this to Profile System Administrator and
no other profile/user has Customize Application privileges or no other user w/ Customize Application privileges is logged in to undo (in Setup)...
TL;DR: Don't use Single Logout (SLO) in SAML. Terminate your app's local session and that's it.
SLO might work under a number of carefully curated assumptions. In practice there are a number of issues with "single logout". Top two problems:
Asynchronous nature of the front-channel flavor of SLO. (Salesforce and virtually all other identity or ...
You simply have to set the NameID and SessionIndex Attribute from the SSO Login Assertion in the Logout Request as well. I can see from your Logout Request that you are not doing this, so you get the status:Responder which is a slight hint that something went wrong. If you miss those values Salesforce will not know which Session to terminate.