OWIN Cookie 身份验证 - 使用 Kerberos 委派模拟 SQL Server

Question

在对 Identity 2.0、模拟、委派和 Kerberos 进行了数周的研究之后，我仍然无法找到一种解决方案来模拟我在 MVC 应用程序中使用 OWIN 创建的 ClaimsIdentity 用户。我的方案的具体情况如下。

禁用 Windows 身份验证 + 启用匿名。
我正在使用 OWIN 启动类针对我们的 Active Directory 手动验证用户身份。然后我将一些属性打包到一个 cookie 中，该 cookie 在应用程序的其余部分都可用。 This 是我在设置这些类时引用的链接。

Startup.Auth.cs

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
     AuthenticationType = MyAuthentication.ApplicationCookie,
     LoginPath = new PathString("/Login"),
     Provider = new CookieAuthenticationProvider(),
     CookieName = "SessionName",
     CookieHttpOnly = true,
     ExpireTimeSpan = TimeSpan.FromHours(double.Parse(ConfigurationManager.AppSettings["CookieLength"]))
});

AuthenticationService.cs

    using System;
    using System.DirectoryServices.AccountManagement;
    using System.DirectoryServices;
    using System.Security.Claims;
    using Microsoft.Owin.Security;
    using System.Configuration;
    using System.Collections.Generic;

    using System.Linq;

    namespace mine.Security
    {
        public class AuthenticationService
        {
            private readonly IAuthenticationManager _authenticationManager;
            private PrincipalContext _context;
            private UserPrincipal _userPrincipal;
            private ClaimsIdentity _identity;

        public AuthenticationService(IAuthenticationManager authenticationManager)
        {
            _authenticationManager = authenticationManager;
        }

        /// <summary>
        /// Check if username and password matches existing account in AD. 
        /// </summary>
        /// <param name="username"></param>
        /// <param name="password"></param>
        /// <returns></returns>
        public AuthenticationResult SignIn(String username, String password)
        {

            // connect to active directory
            _context = new PrincipalContext(ContextType.Domain,
                                            ConfigurationManager.ConnectionStrings["LdapServer"].ConnectionString,
                                            ConfigurationManager.ConnectionStrings["LdapContainer"].ConnectionString,
                                            ContextOptions.SimpleBind,
                                            ConfigurationManager.ConnectionStrings["LDAPUser"].ConnectionString,
                                            ConfigurationManager.ConnectionStrings["LDAPPass"].ConnectionString);

            // try to find if the user exists
            _userPrincipal = UserPrincipal.FindByIdentity(_context, IdentityType.SamAccountName, username);

            if (_userPrincipal == null)
            {
                return new AuthenticationResult("There was an issue authenticating you.");
            }

            // try to validate credentials
            if (!_context.ValidateCredentials(username, password))
            {
                return new AuthenticationResult("Incorrect username/password combination.");
            }

            // ensure account is not locked out
            if (_userPrincipal.IsAccountLockedOut())
            {
                return new AuthenticationResult("There was an issue authenticating you.");
            }

            // ensure account is enabled
            if (_userPrincipal.Enabled.HasValue && _userPrincipal.Enabled.Value == false)
            {
                return new AuthenticationResult("There was an issue authenticating you.");
            }

            MyContext dbcontext = new MyContext();
            var appUser = dbcontext.AppUsers.Where(a => a.ActiveDirectoryLogin.ToLower() == "domain\\" +_userPrincipal.SamAccountName.ToLower()).FirstOrDefault();
            if (appUser == null)
            {
                return new AuthenticationResult("Sorry, you have not been granted user access to the MED application.");
            }

            // pass both adprincipal and appuser model to build claims identity
            _identity = CreateIdentity(_userPrincipal, appUser);
            _authenticationManager.SignOut(MyAuthentication.ApplicationCookie);
            _authenticationManager.SignIn(new AuthenticationProperties() { IsPersistent = false }, _identity);


            return new AuthenticationResult();
        }

        /// <summary>
        /// Creates identity and packages into cookie
        /// </summary>
        /// <param name="userPrincipal"></param>
        /// <returns></returns>
        private ClaimsIdentity CreateIdentity(UserPrincipal userPrincipal, AppUser appUser)
        {

            var identity = new ClaimsIdentity(MyAuthentication.ApplicationCookie, ClaimsIdentity.DefaultNameClaimType, ClaimsIdentity.DefaultRoleClaimType);
            identity.AddClaim(new Claim("http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider", "Active Directory"));
            identity.AddClaim(new Claim(ClaimTypes.GivenName, userPrincipal.GivenName));
            identity.AddClaim(new Claim(ClaimTypes.Surname, userPrincipal.Surname));
            identity.AddClaim(new Claim(ClaimTypes.NameIdentifier, userPrincipal.SamAccountName));
            identity.AddClaim(new Claim(ClaimTypes.Name, userPrincipal.SamAccountName));
            identity.AddClaim(new Claim(ClaimTypes.Upn, userPrincipal.UserPrincipalName));


            if (!String.IsNullOrEmpty(userPrincipal.EmailAddress))
            {
                identity.AddClaim(new Claim(ClaimTypes.Email, userPrincipal.EmailAddress));
            }

            // db claims
            if (appUser.DefaultAppOfficeId != null)
            {
                identity.AddClaim(new Claim("DefaultOffice", appUser.AppOffice.OfficeName));
            }

            if (appUser.CurrentAppOfficeId != null)
            {
                identity.AddClaim(new Claim("Office", appUser.AppOffice1.OfficeName));
            }

            var claims = new List<Claim>();
            DirectoryEntry dirEntry = (DirectoryEntry)userPrincipal.GetUnderlyingObject();

            foreach (string groupDn in dirEntry.Properties["memberOf"])
            {
                string[] parts = groupDn.Replace("CN=", "").Split(',');
                claims.Add(new Claim(ClaimTypes.Role, parts[0]));
            }

            if (claims.Count > 0)
            {
                identity.AddClaims(claims);
            }


            return identity;
        }

        /// <summary>
        /// Authentication result class
        /// </summary>
        public class AuthenticationResult
        {
            public AuthenticationResult(string errorMessage = null)
            {
                ErrorMessage = errorMessage;
            }

            public String ErrorMessage { get; private set; }
            public Boolean IsSuccess => String.IsNullOrEmpty(ErrorMessage);
        }
    }
}

那部分似乎工作得很好。但是，在调用数据库时，我需要能够模拟 ClaimsIdentity，因为数据库上有角色级别的安全设置。对于该用户会话的其余部分，我需要在 ClaimsIdentity 的上下文中完成连接。

• 我已经为 Kerberos 设置了 SPN，我知道它可以工作。这个应用程序是 以前使用 Kerberos 委托进行 Windows 身份验证，并且可以正常工作。
• 应用程序池在 SPN 中使用的具有委托权限的服务帐户下运行。
• 我创建的 Identity 对象几乎只在应用程序上下文中使用。我的意思是我主要从 Active Directory 中获取所有必要的属性，但是将从数据库中创建两个。此标识不直接映射到 sql 表或任何其他数据源。

有人可以帮我指出一个示例，在该示例中我可以在对 SQL Server 数据库进行数据库查询时模拟 ClaimsIdentity 对象吗？

Answer 1

也许我误解了这个问题，但是：

对于使用 Windows 身份验证建立 SQL 服务器连接，连接字符串必须使用“集成安全性”，这意味着它将使用建立连接的当前安全上下文。通常这将是您的 AppPool 用户，在您的情况下是服务帐户。据我所知，you can't propagate your impersonation to the AppPool thread automatically using Kerberos auth。这是我找到的报价：

在 IIS 中，只有基本身份验证使用安全令牌登录用户 通过网络流向远程 SQL 服务器。默认情况下， 与身份结合使用的其他 IIS 安全模式 配置元素设置不会产生可以 向远程 SQL Server 进行身份验证。

因此，如果您想模拟其他用户，则必须在您模拟的用户的主体下启动一个新线程。这样，集成安全连接将使用该用户的 Windows Auth 连接到 SQL Server。

我不确定该怎么做，但这里有一些东西可能会推动你朝着正确的方向前进：

public void NewThreadToRunSQLQueries(object claimsIdentity) {
    if (claimsIdentity as ClaimsIdentity == null) {
        throw new ArgumentNullException("claimsIdentity");
    }

    ClaimsIdentity claimsIdentity = (ClaimsIdentity)claimsIdentity;
    var claimsIdentitylst = new ClaimsIdentityCollection(new List<IClaimsIdentity> { claimsIdentity });
    IClaimsPrincipal claimsPrincipal = new ClaimsPrincipal(claimsIdentitylst);
    Thread.CurrentPrincipal = claimsPrincipal; //Set current thread principal

    using(SqlConnection connection = new SqlConnection("Server=myServerAddress;Database=myDataBase;Integrated Security=True;")) 
    {
        connection.Open(); //Open connection under impersonated user account
        //Run SQL Queries
    }
}

Thread thread = new Thread(NewThreadToRunSQLQueries);
thread.Start(_identity);

编辑：

关于您对如何使此结构“全局”的评论，假设您可以访问身份验证处理程序中的 HttpContext，您可以这样做：

var principal = new ClaimsPrincipal(_identity);

Thread.CurrentPrincipal = principal;
if (HttpContext.Current != null)
{
     HttpContext.Current.User = principal;
}

理论上，来自 IIS 的工作线程现在应该在经过身份验证的用户（模拟）下运行。与 SQL Server 的可信连接应该是可能的。我说理论上是因为我自己没有尝试过。但最坏的情况是，您可以从 HttpContext 中获取声明以启动一个单独的线程，就像我上面的示例一样。但如果这本身有效，您甚至不必像我最初提到的那样启动一个新线程。

Answer 2

[已解决更新 2-1-19] 我已经写了一篇博文详细介绍了这个过程，它可以在here.

我能够通过执行以下操作来完成此操作。我创建了一个类来使这些方法可重用。在该类中，我使用System.IdentityModel.Selectors 和System.IdentityModel.Tokens 库生成KeberosReceiverSecurityToken 并将其存储在内存中。

public class KerberosTokenCacher
{
    public KerberosTokenCacher()
    {

    }

    public KerberosReceiverSecurityToken WriteToCache(string contextUsername, string contextPassword)
    {
        KerberosSecurityTokenProvider provider =
                        new KerberosSecurityTokenProvider("YOURSPN",
                        TokenImpersonationLevel.Impersonation,
                        new NetworkCredential(contextUsername.ToLower(), contextPassword, "yourdomain"));

        KerberosRequestorSecurityToken requestorToken = provider.GetToken(TimeSpan.FromMinutes(double.Parse(ConfigurationManager.AppSettings["KerberosTokenExpiration"]))) as KerberosRequestorSecurityToken;
        KerberosReceiverSecurityToken receiverToken = new KerberosReceiverSecurityToken(requestorToken.GetRequest());

        IAppCache appCache = new CachingService();
        KerberosReceiverSecurityToken tokenFactory() => receiverToken;

        return appCache.GetOrAdd(contextUsername.ToLower(), tokenFactory); // this will either add the token or get the token if it exists

    }

    public KerberosReceiverSecurityToken ReadFromCache(string contextUsername)
    {
        IAppCache appCache = new CachingService();
        KerberosReceiverSecurityToken token = appCache.Get<KerberosReceiverSecurityToken>(contextUsername.ToLower());

        return token;
    }

    public void DeleteFromCache(string contextUsername)
    {
        IAppCache appCache = new CachingService();
        KerberosReceiverSecurityToken token = appCache.Get<KerberosReceiverSecurityToken>(contextUsername.ToLower());

        if(token != null)
        {
            appCache.Remove(contextUsername.ToLower());
        }
    }

}

现在，当用户使用我的 AuthenticationService 登录时，我会创建票证并将其存储在内存中。当他们注销时，我会执行相反的操作并从缓存中删除票证。最后一部分（我仍在寻找更好的方法来完成此任务），我在我的 dbcontext 类的构造函数中添加了一些代码。

public MyContext(bool impersonate = true): base("name=MyContext")
{
    if (impersonate)
    {
        var currentUsername = HttpContext.Current.GetOwinContext().Authentication.User?.Identity?.Name;

        if (!string.IsNullOrEmpty(currentUsername)){

            KerberosTokenCacher kerberosTokenCacher = new KerberosTokenCacher();
            KerberosReceiverSecurityToken token = kerberosTokenCacher.ReadFromCache(currentUsername);

            if (token != null)
            {
                token.WindowsIdentity.Impersonate();
            }
            else
            {
                // token has expired or cache has expired so you must log in again
                HttpContext.Current.Response.Redirect("Login/Logoff");
            }

        }
    }
}

显然它绝对不是完美的，但它允许我对活动目录使用 Owin Cookie 身份验证并生成 Kerberos 票证，从而允许在经过身份验证的用户的上下文中连接到 SQL 数据库。

Answer 3

我猜您缺少 IIS 中的配置点，您需要允许 IIS 将该用户上下文传递给您，这不是默认设置。

在您尝试“修复”您的代码之前，请查看this document。如果这无助于让我们知道并告诉我们您的设置，那么仅靠代码可能无法解决问题。