Федеративные аутентификации - два печенья, первый печенье имеет закрытие тегов XML

Question

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

Токен довольно большой, поэтому печенье делится на два печенья. 99% времени все работает правильно, вот пример из двух печений от успешной регистрации, как только они были 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> 

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

Exception information: Exception type: FormatException Exception message: The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters. at System.Convert.FromBase64_Decode(Char* startInputPtr, Int32 inputLength, Byte* startDestPtr, Int32 destLength) at System.Convert.FromBase64CharPtr(Char* inputPtr, Int32 inputLength)
at System.Convert.FromBase64String(String s) at System.IdentityModel.Services.SessionAuthenticationModule.TryReadSessionTokenFromCookie(SessionSecurityToken& sessionToken) at System.IdentityModel.Services.SessionAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs eventArgs) at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

I logge d 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></SecurityContextToken>, которые не должны быть там, потому что XML-замкнуто в второй файл cookie.

Я думаю, что это то, что вызывает ошибку.

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

Answer 1

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

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

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

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

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