Предоставленный токен защиты от подделки был предназначен для пользователя "xxx", но текущий пользователь ""

Question

Привет, я просмотрел много SO страниц на эту тему, но моя немного отличается.Это не имеет ничего общего с защищенной от подделки страницей входа в систему или пользователями, нажимающими кнопку назад.В нашем университете мы используем CoSign Мичиганского университета в качестве решения для единого входа.Пользователи проходят аутентификацию через cosign, и в случае успеха имя пользователя предоставляется сервером IIS в Request.ServerVariables ["REMOTE_USER"] и может затем использоваться для авторизации и т. Д.

Вот некоторый код: в global.asax.cs:

Session["username"] = Request.ServerVariables["REMOTE_USER"];

На каждой странице, которая может использовать Ajax (в файле Init.js; код из https://blog.alexmaccaw.com/jswebapps-csrf):

$(document).ready(function () {
    SetCSRFHeader();
}
function SetCSRFHeader() {
var CSRF_HEADER = 'RequestVerificationToken';

var setCSRFToken = function (securityToken) {
    jQuery.ajaxPrefilter(function (options, _, xhr) {
        if (!xhr.crossDomain)
            xhr.setRequestHeader(CSRF_HEADER, securityToken);
    });
};
var theTokenVal = $('#__bothTokens').val();
setCSRFToken(theTokenVal);
}

В _Layout.cshtml:

@Html.AntiForgeryToken()
@{
string cookieToken, formToken, bothTokens;
AntiForgery.GetTokens(null, out cookieToken, out formToken);
bothTokens = cookieToken + ":" + formToken;
}
<input type="hidden" id="__bothTokens" value="@(bothTokens)" />

Я также написал класс, который реализует IHttpModule для проверки всех запросов POST для включенного заголовка, его анализа и проверки (код из https://security.stackexchange.com/questions/91164/how-to-check-the-origin-header-server-wide-in-iis-to-prevent-csrf):

public class HeaderCheck : IHttpModule
{
     public HeaderCheck()
    {
    }

    public void Init(HttpApplication application)
    {
        application.BeginRequest +=
            (new EventHandler(this.Application_BeginRequest));
    }

    private void Application_BeginRequest(Object source,
         EventArgs e)
    {
        HttpApplication application = (HttpApplication)source;
        HttpContext context = application.Context;
        int errCode = 0;
        int STATCODE = 403;
        string cookieToken = "";
        string formToken = "";
        if (context.Request.HttpMethod == "POST") // only on POST requests
        {
            if (context.Request.Headers["Content-Type"] != null) 
            {
                if (context.Request.Headers["Content-Type"] == "application/json;") // JSON check
                {
                    if (context.Request.Headers["RequestVerificationToken"] != null)
                    {
                        string tokenHeaders = context.Request.Headers["RequestVerificationToken"]; 
                        string[] tokens = tokenHeaders.Split(':');
                        if (tokens.Length == 2)
                        {
                            cookieToken = tokens[0].Trim();
                            formToken = tokens[1].Trim();
                        }
                    }
                    else
                    {
                        errCode = 3;
                    }
                }
                else if (context.Request.Headers["Content-Type"].Length >= 19)
                {
                    if (context.Request.Headers["Content-Type"].Substring(0, 19) == "multipart/form-data") // Form check
                    {
                        HttpCookie cookie = new HttpCookie("__RequestVerificationToken");
                        cookie = context.Request.Cookies["__RequestVerificationToken"];
                        formToken = context.Request.Form["__RequestVerificationToken"];
                        if (formToken == null) { tokenstr = "form null"; }
                        if (cookie != null)
                        {
                            cookieToken = cookie.Value;
                            System.Web.Helpers.AntiForgery.Validate(cookieToken, formToken);
                        }
                        else // cookie is null
                        {
                            errCode = 4;
                        }
                    }
                }
                else // neither acceptable content form
                {
                    errCode = 5;
                }
            }
            else // content type should not be null
            {
                errCode = 6;
            }
            if (errCode > 0)
            {
                try
                {
                    System.Web.Helpers.AntiForgery.Validate(cookieToken, formToken);
                }
                catch (HttpAntiForgeryException e2)
                {
                    string err = @"Antiforgery tokens not validated" +
                        "<br><b>Error in: </b>"
                        + context.Request.Url.ToString()
                        + "<br><b>Error Message: </b>"
                        + e2.Message.ToString()
                        + "<br><b>Stack Trace:</b><br>"
                        + e2.StackTrace.ToString();
                    EmailContext.sendEmailOnError(err); // sends email to me for debugging
                }
            }

            if (errCode > 0)
            {
                context.Response.StatusCode = STATCODE;
                context.Response.Flush();
                context.Response.End();
            }
        }
    }

    public void Dispose() { }

}
}

Мои вопросы: почему я получаюошибка в названии этого вопроса? Как AntiForgeryValidate узнает, что токен предназначен для меня, но каким-то образом сгенерированный токен предназначен для текущего пользователя ""? Есть ли способ поместить пользователя в токен? Я даже пыталсясовет на Перезагрузить AntiForgeryToken после входа в систему , чтобы всегда регенерировать токен при первом обращении пользователя к домашней странице (так как он уже вошел в систему в этот момент.Имеет ли это какое-либо отношение к разработке в visual studio в HTTP, но среда приема, которая защищена косинусом, - это https?Это как-то связано с тем, что IIS настроен для анонимной аутентификации?(Я думаю, что это должно быть запущено под cosign).

Спасибо за любой совет.

РЕДАКТИРОВАТЬ: Все больше и больше я думаю, что это связано с тем, что анонимная проверка подлинности IIS является единственным режимом, который включен,Но любой другой режим требует своего рода второго входа в систему, и поскольку cosign является поставщиком аутентификации, это не помогает.Так что, если у кого-то есть идеи, как программно вставить учетные данные пользователя, полученные от cosign, в IIS, это может стать шагом вперед.