Нашей организации отдела продаж необходимо предоставить внешнему приложению некоторые функции в виде класса REST API. Мы создали класс вершины (@RestResource(urlMapping='')), теперь для предоставления доступа к внешнему приложению:

  • Мы создали нового пользователя интеграции с ограниченным доступом к профилю и включенным API = true.
  • Мы предоставили учетные данные этого пользователя внешнему приложению.
  • Мы создали связанное приложение и предоставили client_id и secret внешнему приложению.
  • Мы предоставляем URL-адреса oauth Salesforce для внешнего приложения.
  • Внешнее приложение использует поток аутентификации oauth по имени пользователя и паролю, а отдел продаж использует эти данные для получения токена доступа.

Мы хотели бы изучить способ без необходимости создавать пользователя интеграции и делиться учетными данными этого пользователя.

Как этого добиться?

1
Walker 30 Июл 2019 в 17:40
1
Вы предлагаете открыть свой REST-сервис вообще без аутентификации, то есть в общедоступном Интернете? Или вы ищете решение для аутентификации, которое не требует учетных данных?
 – 
David Reed
29 Июл 2019 в 14:50
Мы ищем решение для аутентификации, которое не требует учетных данных. Мы бы предпочли, чтобы нам не нужно было настраивать пользователя в Salesforce для интеграции.
 – 
Walker
29 Июл 2019 в 14:53

1 ответ

Лучший ответ

«Аутентификация без учетных данных» довольно близко к тому, чтобы быть неправильным. По определению, если вы хотите аутентифицировать вызывающего абонента, вам нужны какие-то учетные данные, и лучшим и наиболее безопасным решением является использование пользователя Salesforce, аутентифицированного через OAuth.

Существует еще один вариант, который подходит для определенных ситуаций, но не является универсальной заменой аутентификации на основе учетных данных: вебхук. Веб-перехватчики открыты для открытого мира и вручную удостоверяют, что входящие сообщения исходят от некоторого клиента, который знает предварительно общий секрет. Они делают это, проверяя подпись HMAC (грубо говоря, криптографически безопасный хэш содержимого сообщения плюс некоторый предварительно общий секрет).

Класс Apex веб-перехватчика представлен миру как служба REST без проверки подлинности на сайте Force.com.

Таким образом, веб-перехватчики обеспечивают проверку целостности сообщений и своего рода аутентификацию без совместного использования учетных данных пользователя. Однако они имеют ряд существенных ограничений.

  • Если несколько вызывающих абонентов используют один и тот же предварительно общий секрет, вы не можете отличить их друг от друга, и нет никакого контрольного следа того, какой клиент сделал какой запрос.
  • Вам нужно написать больше кода для аутентификации как на отправляющей, так и на принимающей стороне.
  • В криптографическом коде легко сделать ошибки, которые снижают или разрушают безопасность вашего решения.
  • Получающим пользователем будет пользователь Site Guest, в контексте которого запускается класс Apex. Это накладывает множество ограничений на то, что вы можете делать, на основе разрешений, и может конфликтовать с другими вещами, которые вы надеетесь запустить на этом Сайте.

В большинстве ситуаций я бы рекомендовал использовать пользователя интеграции.

Пользователь интеграции всегда должен проходить аутентификацию через OAuth и сохранять токен обновления (если только не используется поток JWT, в этом случае он должен хранить имя пользователя и сертификат). Удаленная система не должна хранить имя пользователя и пароль. Однако для аутентификации в Salesforce всегда требуется, чтобы пользователь существовал в целевой системе.

3
David Reed 30 Июл 2019 в 17:16
Использование пользователя интеграции также означало бы совместное использование его учетных данных. Кто-то поднял некоторые вопросы по этому поводу. Можно ли пройти аутентификацию без необходимости делиться учетными данными пользователя интеграции с Salesforce?
 – 
Walker
30 Июл 2019 в 11:17
1
Пользователи интеграции не должны быть разделены между соединениями. Вы можете использовать один для нескольких интеграций или один для каждого. Вам также не нужно фактически передавать учетные данные. Удаленная система должна пройти аутентификацию с использованием OAuth.
 – 
David Reed
30 Июл 2019 в 14:30
Сможет ли удаленная система аутентифицироваться с помощью Salesforce с использованием oauth без необходимости учетных данных пользователя integratino и только с идентификатором и секретом клиента подключенного приложения? Нам не нужно какое-либо ручное вмешательство, поскольку REST API Salesforce будет вызываться внешним приложением через код.
 – 
Walker
30 Июл 2019 в 17:14
1
Нет. У вас всегда должен быть пользователь, если вы хотите пройти аутентификацию в Salesforce. Чего делать не следует, так это хранить имя пользователя и пароль. См. мое редактирование выше.
 – 
David Reed
30 Июл 2019 в 17:17
2
Идентификатор клиента и секрет клиента не являются учетными данными. Они идентифицируют ваше приложение. Я хочу внести ясность: вы не можете пройти аутентификацию в Salesforce без учетной записи пользователя. Полная остановка. Вы можете выбрать поток OAuth, соответствующий вашей ситуации, но учетная запись пользователя всегда будет задействована.
 – 
David Reed
30 Июл 2019 в 17:48