Яка різниця між інтегрованою безпекою = правда та інтегрованою безпекою = SSPI?

У мене є два додатки, які використовують інтегровану безпеку. Один призначає Integrated Security = trueрядок з'єднання, а інший встановлює Integrated Security = SSPI.

У чому різниця між SSPIта trueв контексті інтегрованої безпеки?

На думку Microsoft, це те саме.

Коли falseв з’єднанні вказані ідентифікатор користувача та пароль. Якщо це правда, для автентифікації використовуються поточні облікові записи Windows.
Визнані значення true, false, yes, no, і sspi(настійно рекомендується), що еквівалентно true.

Integrated Security=true;працює не у всіх постачальників SQL, він викидає виняток при використанні з OleDbпровайдером.

Таким чином, в основному Integrated Security=SSPI;є кращим, оскільки працює з обома SQLClient& OleDBпровайдером.

Ось повний набір синтаксисів відповідно до MSDN - Syntax String Syntax (ADO.NET)

Використання автентифікації Windows

Для підключення до сервера баз даних рекомендується використовувати автентифікацію Windows, широко відому як інтегрована безпека. Щоб вказати автентифікацію Windows, ви можете використовувати будь-яку з наступних двох пар ключових значень із постачальником даних. NET Framework для SQL Server:

 Integrated Security = true;
 Integrated Security = SSPI;

Однак лише другий працює з постачальником даних .NET Framework OleDb . Якщо ви встановили Integrated Security = trueдля ConnectionString, викидається виняток.

Щоб вказати автентифікацію Windows у постачальника даних. NET Framework для ODBC, ви повинні використовувати наступну пару ключ-значення.

Trusted_Connection = yes;

Джерело: MSDN: Робота з рядками підключення

На багато питань отримуємо відповіді, якщо ми .Net Reflectorбачимо фактичний код SqlConnection:) trueі sspiоднакові:

internal class DbConnectionOptions

...

internal bool ConvertValueToIntegratedSecurityInternal(string stringValue)
{
    if ((CompareInsensitiveInvariant(stringValue, "sspi") || CompareInsensitiveInvariant(stringValue, "true")) || CompareInsensitiveInvariant(stringValue, "yes"))
    {
        return true;
    }
}

...

EDIT 20.02.2018 Тепер у .Net Core ми можемо побачити його відкрите джерело на github! Пошук методу ConvertValueToIntegratedSecurityInternal:

https://github.com/dotnet/corefx/blob/fdbb160aeb0fad168b3603dbdd971d568151a0c8/src/System.Data.SqlClient/src/System/Data/Common/DbConnectionOptions.cs

Вбудована безпека = Неправда: ідентифікатор користувача та пароль вказані у з'єднанні. Інтегрована безпека = вірно: поточні облікові дані Windows використовуються для аутентифікації.

Вбудована безпека = SSPI: це рівнозначно істині.

Ми можемо уникати атрибутів імені користувача та пароля з рядка з'єднання та використовувати інтегровану безпеку

Дозвольте почати з Integrated Security = false

false Ідентифікатор користувача та пароль вказані в рядку з'єднання.
true Встановлення облікових даних Windows використовується для аутентифікації.

Визнані значення true, false, yes, no, і SSPI.

Якщо User IDі Passwordвизначені і Integrated Security встановлений на true, то User IDі Passwordбуде ігноруватися і буде використовуватися Integrated Security

Зауважте, що рядки з'єднання визначаються тим, що і як ви підключаєтесь до даних. Вони підключаються до однієї бази даних, але в першу чергу використовується постачальник даних .NET Framework Data для SQL Server. Вбудована безпека = True не працює для OleDb.

• Джерело даних =; Початковий каталог = aspnetdb; інтегрована безпека = істина
• Провайдер = SQLOLEDB; Джерело даних =; Комплексна безпека = SSPI; Початковий каталог = aspnetdb

Якщо ви сумніваєтеся, використовуйте підключення даних Visual Studio Server Explorer.

• Що таке sspi ?
• Синтаксис рядків з'єднання

Істинне дійсне, лише якщо ви використовуєте бібліотеку .NET SqlClient. Він недійсний під час використання OLEDB. Там, де SSPI недоступний для обох ви використовуєте бібліотеку .net SqlClient або OLEDB.

На мій погляд,

Якщо ви не використовуєте інтегровану безпеку = SSPI, вам потрібно ввести жорсткий код імені користувача та пароля в рядку з'єднання, що означає "відносно небезпечно", тому що, тому що всі співробітники мають доступ, навіть колишній працівник може зловмисно використовувати інформацію.