Безопасность с использованием поставщика членства, который будет поддерживать Active Directory и собственный поставщик на заказ

Question

У меня есть задача справиться с безопасностью в моем. Net-приложении, так как он работает, так это, если пользователь вошел в систему Active Directory и имя пользователя AD находится в базе данных, тогда они будут введены.

На тех же основаниях, если имя пользователя AD нет в базе данных, тогда им будет предложено войти в систему с именем пользователя и паролем в базе данных.

Так что мне нужен какой-то вид входа в систему режима микширования, используя поставщик членства и роли.

Где у меня возникают проблемы, где вы обнаруживаете, может ли пользователь войти в систему с использованием AD, поэтому они автоматически регистрируются.

Answer 1

Похоже, вам понадобится реализовать пользовательский элемент MembershipProvider, который наследуется от ActiveDirectoryMembershipProvider.

Как минимум, вам необходимо переопределить ValidateUser, чтобы, если base.ValidateUser возвращает false, вы можете попытаться проверить пользователя в своей базе данных SQL. Следующий пример кода работает в моем тестовом приложении, однако я не реализовал метод SQL. Это должно быть довольно прямо для вас.

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Text; 
using System.Web.Security; 
using System.Configuration; 
using System.Configuration.Provider; 

namespace Research.Web.Security 
{ 
    public class MixedMembershipProvider : ActiveDirectoryMembershipProvider 
    { 
     protected String SqlConnectionString { get; private set; } 

     private String GetConnectionString(String connectionStringName) 
     { 
      if (string.IsNullOrEmpty(connectionStringName)) 
       throw new ProviderException("ConnectionStringName must be specified."); 

      ConnectionStringSettings settings = ConfigurationManager.ConnectionStrings[connectionStringName]; 
      if (settings == null) 
      { 
       throw new ProviderException(String.Format("Connection string {0} not found.", connectionStringName)); 
      } 
      return settings.ConnectionString; 
     } 

     public override void Initialize(String name, System.Collections.Specialized.NameValueCollection config) 
     { 
      this.SqlConnectionString = GetConnectionString(config["sqlConnectionStringName"]); 
      config.Remove("sqlConnectionStringName"); 

      base.Initialize(name, config); 
     } 

     public override Boolean ValidateUser(String username, String password) 
     { 
      if (!base.ValidateUser(username, password)) // validate using AD first 
      { 
       return ValidateUserSql(username, password); // if not in AD, check SQL 
      } 
      else 
      { 
       return true; 
      } 
     } 

     private Boolean ValidateUserSql(String username, String password) 
     { 
      // look up your account in SQL here 
      return true; 
     } 
    } 
} 

Ваш веб-конфигурации будет выглядеть следующим образом:

<configuration> 
    <!-- usual config stuff omitted --> 
    <connectionStrings> 
    <add name="SqlDefault" connectionString="Server=localhost;database=mydatabase;Integrated Security=SSPI;" providerName="System.Data.SqlClient" /> 
    <add name="ActiveDirectoryDefault" connectionString="LDAP://mydomain.com/DC=mydomain,DC=com" /> 
    </connectionStrings> 

    <system.web> 
<!-- usual config stuff omitted --> 
    <membership defaultProvider="Mixed"> 
     <providers> 
     <clear/> 
     <add name="Mixed" 
      type="Research.Web.Security.MixedMembershipProvider, Research.Web" 
      applicationName="/" 
      connectionStringName="ActiveDirectoryDefault" 
      sqlConnectionStringName="SqlDefault" 
      connectionUsername="mydomain\myadmin" 
      connectionPassword="mypass"/> 
     </providers> 
    </membership> 
    <!--- usual config stuff omitted --> 
    </system.web> 
</configuration> 

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