Генерация криптографически маркеров безопасной аутентификации
Причина, по которой следующие две строки терпят неудачу, заключается в том, что нет определения в ContainerHandler, которое сделало бы успешной реализацию шаблона с этими аргументами шаблона.
ContainerHandler handler1; //compile error
ContainerHandler handler2; //compile error
Если вы предоставите определение для шаблона, например, как это:
template
struct ContainerHandler {};
Компиляция будет успешной. См. демо здесь .
РЕДАКТИРОВАТЬ:
Нет. Я ожидаю получить ошибку компиляции при вызове функции шаблона "container_handler ();" (в первой части кодов).
blockquote>Параметр
int_tвcontainer_handlerимеет значение по умолчанию, поэтому он компилируетсяcontainer_handler. Отсутствие значения по умолчанию вызовет сбой компиляции.();
См. демо здесь .
6 ответов
Основываясь на отзывах других ответов на этот вопрос, дополнительных исследованиях и обсуждениях в автономном режиме, вот что мы в итоге сделали ...
Довольно быстро было отмечено, что Модель взаимодействия здесь по сути точно такая же, как модель, используемая при проверке подлинности с помощью форм в ASP.NET, когда установлен флажок «запомнить меня». Это просто не веб-браузер, выполняющий HTTP-запросы. Наш «билет» эквивалентен cookie, который устанавливает аутентификация с помощью форм. Аутентификация с помощью форм по умолчанию использует подход «зашифровать некоторые данные с помощью секретного ключа».
В нашей веб-службе входа в систему мы используем этот код для создания билета:
string[] userData = new string[4];
// fill the userData array with the information we need for subsequent requests
userData[0] = ...; // data we need
userData[1] = ...; // other data, etc
// create a Forms Auth ticket with the username and the user data.
FormsAuthenticationTicket formsTicket = new FormsAuthenticationTicket(
1,
username,
DateTime.Now,
DateTime.Now.AddMinutes(DefaultTimeout),
true,
string.Join(UserDataDelimiter, userData)
);
// encrypt the ticket
string encryptedTicket = FormsAuthentication.Encrypt(formsTicket);
Затем у нас есть атрибут поведения операций для служб WCF, который добавляет IParameterInspector, который проверяет действительный билет в заголовках HTTP для запроса. Разработчики помещают этот атрибут поведения операции в операции, требующие аутентификации. Вот как этот код анализирует билет:
// get the Forms Auth ticket object back from the encrypted Ticket
FormsAuthenticationTicket formsTicket = FormsAuthentication.Decrypt(encryptedTicket);
// split the user data back apart
string[] userData = formsTicket.UserData.Split(new string[] { UserDataDelimiter }, StringSplitOptions.None);
// verify that the username in the ticket matches the username that was sent with the request
if (formsTicket.Name == expectedUsername)
{
// ticket is valid
...
}
Building your own authentication system is always a "worst practice". That's the kind of thing best left to professionals who specialize in authentication systems.
If you're bent on building your own "expiring ticket from a login service" architecture rather than re-using an existing one, it's probably a good idea to at least familiarize yourself with the issues that drove the design of similar systems, like Kerberos. A gentle introduction is here:
http://web.mit.edu/kerberos/dialogue.html
It would also be a good idea to take a look at what security holes have been found in Kerberos (and similar systems) over the last 20 years and make sure you don't replicate them. Kerberos was built by security experts and carefully reviewed for decades, and still serious algorithmic flaws are being found in it, like this one:
http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-004-krb4.txt
It's a lot better to learn from their mistakes than your own.
Amazon.com использует токен сообщения HMAC SHA-1 для аутентификации и авторизации запросов. Они используют это для довольно больших коммерческих услуг, поэтому я могу доверять их инженерным решениям. Google публикует OpenSocial API , который в чем-то похож. На основании того, что Google и Amazon.com используют аналогичные и открыто опубликованные подходы к защите веб-запросов, я подозреваю, что это, вероятно, хорошие пути.
Either of the two answers you've provided will suffice. You may find frameworks out there that do this for you, but the truth is it's not that hard to build. (Every company I've worked for has rolled their own.) The choice of database-stored tokens versus encrypted data "cookies" is an architectural decision -- do you want to incur a database lookup on every page view, or would you rather chew up CPU with cookie decryption? In most applications, using encrypted cookies provides a performance win at scale (if that's a concern). Otherwise it's just a matter of taste.
Поскольку вы используете WCF, у вас есть множество вариантов использования CFNetwork - например, NTLM или дайджест-аутентификация:
Я знаю, что это не ответ на ваш конкретный вопрос, но я тоже сталкивался с этой проблемой (iPhone - Tomcat) и решил как можно больше использовать службы аутентификации на веб-сервере. В большинстве случаев нет значительных штрафов за включение аутентификационной информации в каждый запрос. Быстрый поиск в Google обнаруживает множество сообщений в блогах о службах WCF и RESTful (и некоторые связанные вопросы по StackOverflow).
Надеюсь, это поможет!
Это просто похоже на идентификатор сеанса с длинным сроком действия. Здесь могут применяться те же принципы, которые используются для этого в веб-приложениях.
Вместо кодирования информации идентификаторы сеанса выбираются случайным образом из очень большого пространства (128 бит). Сервер ведет запись, связывающую идентификатор сеанса с пользователем и другую желаемую информацию, такую как время истечения срока действия. Клиент представляет идентификатор сеанса по защищенному каналу с каждым запросом.
Безопасность зависит от непредсказуемости идентификаторов сеанса. Сгенерируйте их с помощью криптографического ГСЧ из очень большого пространства.