3

As per the documentation provided on the delegated authentication here https://help.salesforce.com/articleView?id=sso_delauthentication_configuring.htm&type=5 it states that

Add a link to your corporate intranet or other internal site that takes the authenticated user’s credentials and passes them through an HTTP POST to the Salesforce login page. Because Salesforce doesn’t use the password field other than to pass it back to you, don’t pass in a password. Instead, pass another authentication token, such as a Kerberos Ticket, so that your corporate passwords aren’t passed to or from Salesforce.

For the HTTP POST I was able to get it done by setting up a link which will allow the user to click on the link which will redirect the user to the below URL:

https://login.salesforce.com?un=username@gmail.com&pw=Password1234!

This will login the user into the salesforce successfully but the only catch is that the usercredentials becomes visible on the address bar which is a security risk.

Two Questions:

Q1 : Is it fine to send the users credentials as defined in the above request?

Q2 : Salesforce mentions that that we can send the kerberos ticket. Could someone please help on this with more information on how to achieve this?

Improve this question
1
  • developer.secure.force.com/cookbook/recipe/… I found this link - have you tried something along these lines? I don't work with Single Signon in my orgs currently but i thought this might help to at least get you some more information. – Ronnie Jul 27 '18 at 2:34
3
+50

Kerberos is a networking protocol and is the default protocol used by Windows for authentication when joining a Windows domain to establish trust. I don't think you can run a Windows Domain without also running Kerberos on all of the connected machines. See RFC 3244 and RFC 4757 to learn more about the Microsoft specifications and its uses. Kerberos can also be used on Unix, Linux and other platforms, including iOs.

To address your 1st question, it is VERY insecure and not at all recommended to send login using https://login.salesforce.com?un=username@gmail.com&pw=Password1234!! Doing that defeats all of the security benefits of implementing SSO. You're exposing both your usernames and passwords for anyone to hack.

What you may not be aware of is that Salesforce does not retain, doesn't care about, and doesn't want the username or password during delegated authorization. It passes what is receives during log-in to your org via the web service you've configured for authentication. If your service returns "success", it authenticates your user and allows them to log-in to your org. Otherwise, it simply denies the request. It doesn't retain anything related to the transaction. All records are kept in your Salesforce org, not in the idP part of Salesforce.

For your other question, if your users are using Windows machines that are on your network, they should be authenticating with your network using Kerberos. The mere act of logging into to your Domain Servers, should allow them to have an active token that can be sent from their machine to Salesforce. Salesforce can then send it via the web service to your server to validate them. Even when they're not logged in to your org's Domain, I'd expect them to have a refresh token from your Domain servers that Kerberos would send to Salesforce (am not knowledgeable on all the details related to Kerberos, so am "improvising" a bit on the refresh token).

Although it's not in a delegated SSO context, I think you'll find the following article's references to Kerberos helpful as part of a Salesforce SSO AD implementation:

Configure SSO to Salesforce Using Microsoft Active Directory Federation Services as the Identity Provider

EDIT

In Response to comments...

I recommend you read relevant parts of the Single Sign-On Implementation Guide and go to "Sample Delegated Authentication Implementations". Also download the sample code for .NET. Then, review Sample 2 on that page.

When it comes to communities, this kind of Delegated Authentication configuration is not intended to work with Communities. Communities require MyDomain to be enabled while Delegated Authentication does not. More importantly, you cannot log in to a Community from login.saelsforce.com. Each Community has its own login page. You'll want to explore other options such as using Social Sign On instead.

Salesforce Authentication via Delegated Authentication is often a very complex subject and not easy to discuss in this venue. I recommend you explore the vast amount of documentation available to you and try to post new questions of limited scope one at a time as you find you have them.

Other resources I think you may find helpful would include:

Improve this answer
4
  • Regarding the URL https://login.salesforce.com?un=username@gmail.com&pw=Password1234!, I understand that we can send anything as the password, but the username has to be the one that is setup in salesforce otherwise how will salesforce know to perform the delegated authentication because delegated authentication is applicable only if we provide the permission to the user via profiles or permission sets. – Sam Jul 30 '18 at 4:52
  • That's correct. What kind of Domain do you have and do you use SAML for instance? Do your users login to your network before logging in to Salesforce? You should be able to send Salesforce some kind of SAML bearer token for example or a JWT bearer token if they do. I don't know what kind of token Kerberos uses for the login to a network. It would depend on your network setup and your docs should tell you that. I suggest you try the MSN Knowledge Base for more info on Kerberos login & tokens. – crmprogdev Jul 30 '18 at 12:53
  • Yes the user would login to the internal portal and from there they would click link which would redirect them to https://login.salesforce.com?un=sfUserName&pw=hashedString. Once this happens salesforce would send the username, password and the source IP to delegated webservice. Now the question here is, will there be any issues with above redirection? and will it work for communities? – Sam Aug 1 '18 at 12:03
  • @Anamadeya see my edited answer. – crmprogdev Aug 1 '18 at 17:56
0

Take a look at Identity Connect. It will let you use Kerberos [aka Integrated Windows Authentication (IWA)] to authenticate against Active Directory and from there it will SSO to Salesforce via SAML on your user's behalf.

https://trailhead.salesforce.com/en/modules/identity_connect http://resources.docs.salesforce.com/rel1/doc/en-us/static/pdf/identity_connect_impl_guide.pdf (see Chapter 7 for IWA)

Improve this answer
2
  • I went thru the document, but the identity connect is a paid feature and we are looking something that would work without making any purchases. – Sam Aug 2 '18 at 8:56
  • Your best free option is ADFS. – identigral Aug 9 '18 at 19:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.