通过Azure AD身份验证对用户进行身份验证时获取NULL身份 [英] Getting NULL Identity while authenticating user via Azure AD authentication

问题描述

我正在尝试使用WS联合身份验证通过Azure AD对用户进行身份验证.

I am trying to authenticate user by Azure AD using WS-federation.

我已经实现了多种身份验证方案，并使用Challenge()将用户重定向到相应的方案.

I've implemented multiple authentication schemes and redirect the user to the respective schemes using Challenge().

return Challenge(new AuthenticationProperties { RedirectUri = "http://localhost:57826/Account/AzureADLogin"}, authenticationScheme);

这可以将我重定向到Microsoft登录页面，成功登录后，它会将我重定向到操作方法AzureADLogin().

This can redirect me to the Microsoft login page and after successful login, it redirects me to the action method AzureADLogin().

但是以某种方式在AzureADLogin()中，我无法通过此方法登录用户身份(User.Identity.Name).我在响应中收到空声明.

But somehow in AzureADLogin(), I could not able to get logged in user identity(User.Identity.Name) in this method. I'm receiving empty claims in the response.

还在Azure AD中将RedirectURIs设置为" http://localhost:57826/Account/AzureADLogin ".

Also in the Azure AD RedirectURIs is set to "http://localhost:57826/Account/AzureADLogin".

有人知道我做错了什么吗?

Does anyone has idea what I'm doing wrong or missing something?

推荐答案

我刚刚进行了3天的战斗，当我三月份第一次注意到此问题时，我花了几天的时间进行故障排除和重写我的应用程序.就我而言，我有一个.Net 4.5.2应用程序，在使用WSFederation和OWIN登录到Azure AD时已经使用了多年.但是，服务器Win 2016的更新发生在2020年3月，但无法登录.每当我获得登录用户名的位置在System.Web.HttpContext.User.Identity.Name中都是空白，并且每次更新前都会填充该位置.我追溯到服务器2016年KB4537764的更新.(仅供参考，2012年的更新分别为KB4532946和KB4532940).如果删除此更新，则登录有效.再次应用更新将其破坏.我用谷歌搜索KB4537764，直到脸色发青并且总是空着.直到我研究了KB4537764的实际功能(它提到了SameSite的修复程序)之后，我才发现需要做些什么来修复它并在服务器上安装更新.

I just battled this for over 3 days, and I spent several days troubleshooting and rewriting my app when I first noticed this problem in March. In my case, I have a .Net 4.5.2 app that had worked for years when using WSFederation and OWIN to login to Azure AD. However, an update to the server Win 2016 occurred in March 2020 that broke the signin. Every single time the place I got the logged-in User Name was blank in System.Web.HttpContext.User.Identity.Name, and it had been populated each time before the update. I traced it back to in update of KB4537764 on Server 2016. (FYI for anyone else the updates for 2012 are KB4532946 and KB4532940) If I removed the update, the signin worked. Applying the update again broke it. I googled for KB4537764 until I was blue in the face and always came up empty. It wasn't until I researched what KB4537764 actually did - it mentions a fix for SameSite - that I found what I needed to do to fix it and have the update installed on the server.

• 在Nuget软件包管理器中将所有OWIN版本更新到4.1.0

• 您需要配置应用程序以使用SystemWebCookieManager.将其添加到startup.cs中.我将其设置为Configuration(IAppBuilder应用)的第一行

• Update all OWIN versions to 4.1.0 in Nuget Package Manager

• You need to configure the app to use SystemWebCookieManager. Add this in startup.cs. I made it the first line in Configuration(IAppBuilder app)

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    // ...
    CookieManager = new SystemWebCookieManager()
});

使用Microsoft.Owin.Host.SystemWeb并在Startup.cs中使用Microsoft.Owin.Security.Cookies添加上述代码.

在我的PageAuthorize类中，如果System.Web.HttpContext.Current.User.Identity.Name为空白，则进行SSO调用:

Add using Microsoft.Owin.Host.SystemWeb and using Microsoft.Owin.Security.Cookies in Startup.cs for the above code.

In my PageAuthorize class I make the SSO call if System.Web.HttpContext.Current.User.Identity.Name is blank:

公共类PageAuthorize:AuthorizeAttribute {

public class PageAuthorize : AuthorizeAttribute {

private readonly string[] allowedroles;         
public PageAuthorize(params string[] roles)
{
    this.allowedroles = roles;

}


protected override bool AuthorizeCore(HttpContextBase httpContext)
{
    bool authorize = false;      

    if (System.Web.HttpContext.Current.User.Identity.Name=="")
     {
 System.Web.HttpContext.Current.GetOwinContext().Authentication.Challenge(new AuthenticationProperties { RedirectUri = "https://mysite/Home/LoggedIn" }, WsFederationAuthenticationDefaults.AuthenticationType);  
        authorize = true;
    }
    else
    {
        foreach (var role in allowedroles)
        {
            int intLoginId;
            string staffName;
            sysRole sysRole;

            var _staffService = DependencyResolver.Current.GetService<IStaffService>();
            LoginMySelf me = new LoginMySelf(_staffService);
            var Login = me.DetermineLogin(out intLoginId, out staffName, out sysRole);

            //set session vars
            var _sessionManagerService = DependencyResolver.Current.GetService<ISessionManagerService>();
            string strSess = _sessionManagerService.SetLoginSessionVars(Login, intLoginId, "SSO", sysRole.RoleName,
                   staffName, Convert.ToInt32(sysRole.AccessLevelValue));
            System.Web.HttpContext.Current.Session["RoleName"] = sysRole.RoleName;
            System.Web.HttpContext.Current.Session["StaffName"] = staffName;

            if (role == sysRole.RoleName)
            {
                authorize = true;
            }
        }

    }

    return authorize;
}
protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
{
    HttpContext.Current.Response.Redirect("~/Home/NotAuthorized");
}

}

现在，System.Web.HttpContext.Current.User.Identity.Name始终包含我的用户名.

Now the System.Web.HttpContext.Current.User.Identity.Name always contains my username as expected.

以下是我用来隔离和解决问题的参考: - https://github.com/aspnet/AspNetKatana/issues/324 - https://github.com/aspnet/AspNetKatana/wiki/System.Web-response-cookie-integration-issues

Here are references I used to isolate and fix the problem: -https://github.com/aspnet/AspNetKatana/issues/324 -https://github.com/aspnet/AspNetKatana/wiki/System.Web-response-cookie-integration-issues

希望这可以帮助您和其他人.诊断绝对令人发狂，但解决方法很简单！

Hope this helps you and others with this. This was absolutely maddening to diagnose but the fix was simple!

这篇关于通过Azure AD身份验证对用户进行身份验证时获取NULL身份的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！