Является ли зашифрованное настраиваемое поле безопасным способом хранения маркеров OAuth с ограниченным сроком службы для обратных вызовов Apex? - PullRequest
0 голосов
/ 06 сентября 2018

Вызовы Apex используются для интеграции Salesforce с SAP Concur.

  1. Именованные учетные данные несовместимы, потому что Concur возвращает 403 после истечения срока действия токена, тогда как SF ожидает, что 401 узнает, когда обновить токен.
  2. Пользовательские метаданные не могут быть записаны, поэтому токен доступа не может быть обновлен и затем сохранен в записи. Кроме того, это только обеспечено RBAC.
  3. Управляемый пакет не подходит для варианта использования.
  4. Пользовательские настройки имеют максимальную длину поля 255, а длина токена указана в тысячах символов. Та же проблема безопасности, что и метаданных.

Для автоматизированного решения, в котором токен доступа к учетной записи службы хранится и обновляется для использования в обратных вызовах, инициируемых пользователем без необходимости аутентификации пользователя, является ли пользовательский объект с зашифрованными настраиваемыми полями жизнеспособным (хотя и далеко не идеальным) решением?

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

1 Ответ

0 голосов
/ 06 сентября 2018

Если Named Credential не работает, у вас нет отличного решения. Я не буду хранить токен в полях, потому что ваш пользователь сможет их найти. Я бы устроил закрытый урок и хранил там токен.

...