Федеративная аутентификация - два куки, первый куки имеет закрывающий тег xml

c# asp.net-mvc-4

430 просмотра

1 ответ

204 Репутация автора

Я создаю куки аутентификации для сайта, используя код FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(token);

Токен довольно большой, поэтому cookie разделен на два cookie. В 99% случаев все работает правильно, вот пример двух файлов cookie, полученных после успешного входа в систему после их декодирования Base64:

WebSiteAuth:

<?xml version="1.0" encoding="utf-8"?><SecurityContextTokenp1:Id="_e00ce4ab-> 2439-48d3-a1cd-f6a31180d02f-B99934A3DBEDB9B3EA191AB595FA8011" xmlns:p1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"><Identifier>urn:uuid:adbfc4e1-c4a1-4882-9980-aa59431cdf48</Identifier><Cookie xmlns="http://schemas.microsoft.com/ws/2006/05/security">ENCRYPTED_COOKIE_VALUE

WebSiteAuth1:

ENCRYPTED_COOKIE_VALUE</Cookie></SecurityContextToken>

Но иногда пользователь сталкивается со следующей ошибкой:

Информация об исключении: Тип исключения: FormatException Сообщение об исключении: Входные данные не являются допустимой строкой Base-64, так как содержат неосновные 64 символа, более двух символов заполнения или недопустимый символ среди символов заполнения. в System.Convert.FromBase64_Decode (Char * startInputPtr, Int32 inputLength, Byte * startDestPtr, Int32 destLength) в System.Convert.FromBase64CharPtr (Char * inputPtr, Int32 inputLength)
в System.Convert.FromBase64String (String s) в System.IdentityModel.Services.SessionAuthenticationModule.TryReadSessionTokenFromCookie (SessionSecurityToken & sessionToken) в System.IdentityModel.Services.SessionAuthentication.Text.Exp.Exp.Exp. System.Web.HttpApplication.IExecutionStep.Execute () в System.Web.HttpApplication.ExecuteStep (шаг IExecutionStep, булево и завершено синхронно)

Я зарегистрировал файлы cookie пользователя в тот момент, когда была выдана ошибка, и вот как выглядели файлы cookie после того, как я Base64 расшифровал их.

WebSiteAuth:

<?xml version="1.0" encoding="utf-8"?><SecurityContextToken p1:Id="_3518f851-bbec-4bb3-b7bb-c4c9bd9165e2-978AD0895E2683747B7CAFF4F1C7131B" xmlns:p1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"><Identifier>urn:uuid:dd9a6856-9bd1-486c-9f5c-e980fbcc3b02</Identifier><Cookie xmlns="http://schemas.microsoft.com/ws/2006/05/security">ENCRYPTED_COOKIE_VALUE</Cookie></SecurityContextToken>

WebSiteAuth1:

ENCRYPTED_COOKIE_VALUE</Cookie></SecurityContextToken>

Как вы можете видеть, разница в том, что первый cookie имеет закрывающие теги, </Cookie></SecurityContextToken>которых там быть не должно, потому что xml закрыт во втором cookie.

Я думаю, что это является причиной ошибки.

У кого-нибудь есть опыт решения этой проблемы? Или есть идеи, как я могу это исправить?

Автор: Tim Pickin Источник Размещён: 19.07.2016 09:07

Ответы (1)


1 плюс

204 Репутация автора

Решение

Моим решением было уменьшить размер куки.

В SessionSecurityToken есть настройка, которая называется IsReferenceMode. Поэтому я установил, что это правда. Это означает, что файл cookie хранится на сервере, и на компьютере пользователя сохраняется только ссылка на этот «файл cookie сервера». Это означает, что cookie-файлы намного меньше и не разбиты на два cookie-файла, что позволяет избежать проблемы, с которой я столкнулся, когда первый кусок cookie иногда случайно включал закрывающие теги xml.

Недостатком этого подхода является то, что при перезапуске пула приложений клиент теряет свой файл cookie, даже если он установил, что файл cookie должен быть постоянным. Чтобы обойти это, я смог унаследовать от класса SessionSecurityTokenCache и переопределить методы AddOrUpdate, Get и Remove, чтобы использовать базу данных в качестве хранилища резервных копий, поэтому маркер можно получить, даже если сеанс очищен.

Я адаптировал модель thinktecture, которая находится здесь: https://github.com/identitymodel/Thinktecture.IdentityModel.

Здесь есть хороший блог, объясняющий основы: https://brockallen.com/2013/02/21/server-side-session-token-caching-in-wif-and-thinktecture-identitymodel/

Автор: Tim Pickin Размещён: 29.07.2016 06:35
Вопросы из категории :
32x32