Где хранить токен на предъявителя авторизации в Salesforce?

Question

У нас есть внешний поставщик, который требует, чтобы мы включали токен-носитель в заголовок запроса http, когда мы общаемся с API. Этот токен не следует оставлять в коде в незашифрованном виде, поэтому где лучше всего его хранить? Тип Named Credential не поддерживает хранение простого токена, а опция Custom Setting кажется слишком сложной и ненужной. Это одна строка токена, которая будет использоваться для каждого вызова API независимо от того, какой пользователь. Я много раз искал в Google и не нашел очевидного решения, которое работает.

Answer 1

Есть несколько вариантов, но они ограничены для вашего кода как конечного пользователя. Определенный разработчик / sysadmin узнает значение в конце концов.

Если вы создадите управляемый пакет, вы можете использовать защищенный пользовательский параметр (код управляемого пакета может видеть его, но не код клиента, даже sysadmins)

Отметьте некоторые из них:

• https://developer.salesforce.com/page/Secure_Coding_Storing_Secrets
• https://salesforce.stackexchange.com/questions/226110/what-is-the-best-way-of-storing-username-and-password-in-salesforce
• https://salesforce.stackexchange.com/questions/478/using-transient-keyword-to-store-password-in-hierarchy-custom-setting
• https://salesforce.stackexchange.com/questions/55008/is-encrypting-passwords-in-protected-custom-settings-a-security-requirement

Можно выполнить пользовательскую настройку с 2 текстовыми полями, 1 с ключом шифрования и 1 с зашифрованным ценность в этом. Посмотрите на Crypto class.

Blob exampleIv = Blob.valueOf('Example of IV123');
Blob key = Crypto.generateAesKey(128);
Blob data = Blob.valueOf('Data to be encrypted');
Blob encrypted = Crypto.encrypt('AES128', key, exampleIv, data);

Blob decrypted = Crypto.decrypt('AES128', key, exampleIv, encrypted);
String decryptedString = decrypted.toString();
System.assertEquals('Data to be encrypted', decryptedString);

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