Qual é a diferença entre segurança integrada = segurança verdadeira e integrada = SSPI?

Eu tenho dois aplicativos que usam segurança integrada. Um designa Integrated Security = true na cadeia de conexão e o outro define Integrated Security = SSPI .

Qual é a diferença entre o SSPI e o true no contexto da Segurança Integrada?

Segundo a Microsoft, eles são a mesma coisa.

Quando false , o ID do usuário e a senha são especificados na conexão. Quando verdadeiro, as credenciais atuais da conta do Windows são usadas para autenticação.
Os valores reconhecidos são true , false , yes , no e sspi (altamente recomendado), o que equivale a true .

Integrated Security=true; não funciona em todos os provedores SQL, ele lança uma exceção quando usado com o provedor OleDb .

Então basicamente Integrated Security=SSPI; é preferível, pois funciona com o provedor SQLClient e OleDB .

Aqui está o conjunto completo de syntaxs de acordo com o MSDN – Sintaxe de Cadeia de Conexão (ADO.NET)

Sintaxe de Autenticação do Windows

Usando a autenticação do Windows

Para se conectar ao servidor de database, é recomendável usar a Autenticação do Windows, comumente conhecida como segurança integrada. Para especificar a autenticação do Windows, você pode usar qualquer um dos dois pares de valores de chave a seguir com o provedor de dados. NET Framework para o SQL Server:

  Integrated Security = true; Integrated Security = SSPI; 

No entanto, apenas o segundo funciona com o provedor de dados .NET Framework OleDb . Se você definir Integrated Security = true para ConnectionString, uma exceção será lançada.

Para especificar a autenticação do Windows no provedor de dados. NET Framework para ODBC, você deve usar o seguinte par de valores-chave.

 Trusted_Connection = yes; 

Fonte: MSDN: Trabalhando com seqüências de conexão

Muitas perguntas obtêm respostas se usarmos o .Net Reflector para ver o código real de SqlConnection 🙂 true e sspi são os mesmos:

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

EDIT 20.02.2018 Agora no .Net Core, podemos ver seu código aberto no github! Procure pelo método ConvertValueToIntegratedSecurityInternal:

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

Segurança integrada = Falso: a ID do usuário e a senha são especificadas na conexão. Segurança integrada = true: as credenciais atuais da conta do Windows são usadas para autenticação.

Segurança integrada = SSPI: isso é equivalente a true.

Podemos evitar os atributos de nome de usuário e senha da cadeia de conexão e usar a Segurança Integrada

Deixe-me começar com Integrated Security = false

false ID do usuário e senha são especificados na string de conexão.
true credenciais true conta do Windows são usadas para autenticação.

Os valores reconhecidos são true , false , yes , no e SSPI .

Se a User ID e a Password forem especificados e a Segurança Integrada estiver definida como true , a User ID e a Password serão ignorados e a Segurança Integrada será usada

Observe que as seqüências de conexão são específicas para o que e como você está se conectando aos dados. Eles estão se conectando ao mesmo database, mas o primeiro está usando o .NET Framework Data Provider para SQL Server. Segurança integrada = True não funcionará para o OleDb.

  • Fonte de Dados = .; Catálogo Inicial = aspnetdb; Segurança Integrada = Verdadeiro
  • Provider = SQLOLEDB; Data Source = .; Segurança Integrada = SSPI; Catálogo Inicial = aspnetdb

Em caso de dúvida, use as conexões de dados do Visual Studio Server Explorer.

  • O que é sspi ?
  • Sintaxe de seqüências de conexão

True só é válido se você estiver usando a biblioteca .NET SqlClient. Não é válido ao usar o OLEDB. Onde SSPI é bvaid em ambos ou você está usando biblioteca .net SqlClient ou OLEDB.

No meu ponto de vista,

Se você não usa segurança integrada = SSPI, então você precisa codificar o nome de usuário e senha na seqüência de conexão que significa “relativamente inseguro” porque, porque todos os funcionários têm access, mesmo ex-funcionário poderia usar as informações maliciosamente.