Веб-разработка → Одновременная межсайтовая аутентификация без велосипеда
Одновременная межсайтовая аутентификация (SSO), для чего же она нужна? Допустим у нас есть, назовём его анахроничным термином «портал», с блогами, фотками, фейлами (или файлами, кому как), назовём его fail.ru (не путать с одноимённым сервисом почты на букву М), причём всё это усложнено следующими факторами:
— функционал совершенно разный;
— код написан разными людьми, с испольованием разных технологий;
— работает всё это на разных серверах в разных датацентрах и с разными базами данных;
— сервера находятся на разных доменах.
И вот у такого Кощея нам нужно будет сломать яйцо и дать пользователю возможность зайти только один раз, а потом заходить на все дружественные ресурсы не подтвеждая свою личность ещё раз.
Об этом уже достаточно много писали, причём и код в том числе. Но мы не пойдём по проторенной дороге велосипедостроения, а как настоящие инженеры возьмём готовые наработки и используем их. Способ прост, и подходит даже для такой сложной ситуации.
Далее мы рассмотрим самописные альтернативы, OpenID, OAuth, SAML, и почему всё это в общем случае не слишком хорошее решение, вопросы хранения аутенитификационных данных, а также некоторые вопросы безопасности в которые без хороших знаний самому лезть не стоит, что такое вообще межсайтовая аутентификация, развеем некоторые мифы.
— функционал совершенно разный;
— код написан разными людьми, с испольованием разных технологий;
— работает всё это на разных серверах в разных датацентрах и с разными базами данных;
— сервера находятся на разных доменах.
И вот у такого Кощея нам нужно будет сломать яйцо и дать пользователю возможность зайти только один раз, а потом заходить на все дружественные ресурсы не подтвеждая свою личность ещё раз.
Об этом уже достаточно много писали, причём и код в том числе. Но мы не пойдём по проторенной дороге велосипедостроения, а как настоящие инженеры возьмём готовые наработки и используем их. Способ прост, и подходит даже для такой сложной ситуации.
Далее мы рассмотрим самописные альтернативы, OpenID, OAuth, SAML, и почему всё это в общем случае не слишком хорошее решение, вопросы хранения аутенитификационных данных, а также некоторые вопросы безопасности в которые без хороших знаний самому лезть не стоит, что такое вообще межсайтовая аутентификация, развеем некоторые мифы.
symfony framework → Symfony2\SecurityBundle
Автор рассказывает об устройстве бандла Security (на мой взгляд, самого трудного в понимании для symfony-новичков) и разбирает пример его применения. Статья будет особенно полезна для тех, кто желает знать, как работает их инструмент: Symfony2 Security в общем и FOSUserBundle в частности — однако не подходит для первого знакомства с фреймворком, поскольку требует знания некоторых из его компонент.Статья была опубликована 21 марта 2011 года, когда ещё не вышла финальная версия symfony2.0, однако принципы работы бандла не изменились.
Оригинальная статья — «Symfony2 Blog Application Tutorial Part V: Intro to Security» — часть цикла обучающих статей на примере создания блога.
Есть прямое продолжение/дополнение статьи — «Symfony2 Blog Application Tutorial Part V-2: Testing Secure Pages», где даётся пример тестирования «закрытых» частей приложения.
.NET → Postsharp: авторизация и аутентификация
Одно из самых востребованных применений аспектно-ориентированного программирования это вынос обслуживающего инфраструктурного кода, который часто повторяется в системе, в отдельный класс. Что в свою очередь является проявленем принципа единой ответственности (SRP — Single Responsibility Principle). Очень часто задачи авторизации и аутентификации разбросаны по всему коду проверяя права доступа пользователя. Следствием этого является большая трудоемкость изменений в этой немаловажной части логики, а так же ее общая проверка. Принцип единой ответственности говорит о том, что должна быть только одна причина для изменения класса, так что все что относится к авторизации и аутентификации просто просится в отдельные классы.
Основные методы аутентификации обычно не то, что используется по всему приложению. Например в веб приложениях ввод данных для аутентификации и сама аутентификация происходит на одной странице, после чего информация о пользователе хранится в каком-либо токене со сроком годности. Благодаря этому пользователь может автоматически входить в систему в течении срока работы токена. Таким образом единственным кодом, который пронизывает все страницы приложения будет проверка того, что пользователь до сих пор в системе. Конечно, вы можете использовать PostSharp для такой проверки, но это не лучший способ применения, по моему мнению.
Основные методы аутентификации обычно не то, что используется по всему приложению. Например в веб приложениях ввод данных для аутентификации и сама аутентификация происходит на одной странице, после чего информация о пользователе хранится в каком-либо токене со сроком годности. Благодаря этому пользователь может автоматически входить в систему в течении срока работы токена. Таким образом единственным кодом, который пронизывает все страницы приложения будет проверка того, что пользователь до сих пор в системе. Конечно, вы можете использовать PostSharp для такой проверки, но это не лучший способ применения, по моему мнению.
Вопросы безопасности в веб-технологиях → SRP-6: аутентификация без передачи пароля
Как и было обещано в соседней теме, где рассказывался велосипед, выкладываю описание алгоритма SRP RFC2945 — способе регистрации и аутентификации пользователей безопасным образом по небезопасному каналу. Вот только в процессе подготовки статьи я обнаружил более свежую версию протокола, SRP-6, вместе с реализацией, в связи с чем решил выбросить свои архаичные наработки по SRP-3, и просто дать ссылки на имплементацию новой версии.
Веб-разработка → Межсайтовая авторизация 2
По итогам поста, сделанного в июле 2009 и продолжительным испытаниям, мы пришли к простой и оптимальной для нас схеме межсайтовой авторизации.
Персональные блоги → Зверинец аккаунтов гугла
В общем, не сказать чтобы мне есть на что жаловаться в Гугле. Целиком и полностью функционал мне нравится.
Единственное, чего я так и не могу допетрить: ну чего они так тянут со слиянием аккаунтов?
Восхитившись идеей Google Apps, я прикрутил почту к двум свои доменам. И теперь для каждого у меня отдельный логин и пароль. Кроме того, у меня есть учетка и @gmail.com.
Почему нельзя настроить доступ через один аккаунт ко всем подчиненным доменам, черт возьми? Система аутентификаций-то одна! А те могут быть лишь синонимами.
Единственное, чего я так и не могу допетрить: ну чего они так тянут со слиянием аккаунтов?
Восхитившись идеей Google Apps, я прикрутил почту к двум свои доменам. И теперь для каждого у меня отдельный логин и пароль. Кроме того, у меня есть учетка и @gmail.com.
Почему нельзя настроить доступ через один аккаунт ко всем подчиненным доменам, черт возьми? Система аутентификаций-то одна! А те могут быть лишь синонимами.
Персональные блоги → Двойная Аутидентификация
По работе мне часто приходится работать с компьютерами, которые находятся в домене, отличном от домена моей рабочей машины.
Такое часто случается, когда нужно подключиться с домашней или рабочей машины к TFS, VSS, расшаренной папке или подобному сервису, находящемуся в другой корпоративной сети, например сети клиента.
Каждый, кто сталкивался с подобной задачей, знает — приходится постоянно вводить логин/пароль, при каждой установке соединения, на каждый отдельно взятый сервис.
Не проблема, когда это нужно сделать пару раз, но когда с этим работаешь постоянно — ручной ввод паролей начинает порядком надоедать.
Такое часто случается, когда нужно подключиться с домашней или рабочей машины к TFS, VSS, расшаренной папке или подобному сервису, находящемуся в другой корпоративной сети, например сети клиента.
Каждый, кто сталкивался с подобной задачей, знает — приходится постоянно вводить логин/пароль, при каждой установке соединения, на каждый отдельно взятый сервис.
Не проблема, когда это нужно сделать пару раз, но когда с этим работаешь постоянно — ручной ввод паролей начинает порядком надоедать.
Zend Framework → Zend_Mail отправка писем через SMTP с аутентификацией
Переделывал както один сайтик за горе-создателями и потребовалось мне отправлять почту через SMTP c аутентификацией.
Смотрим в руководство на сайте зенда http://framework.zend.com/manual/ru/zend.mail.smtp-authentication.html
и видим: "… на данный момент SMTP-аутентификация не поддерживается" :(
Что же делать?
Смотрим в руководство на сайте зенда http://framework.zend.com/manual/ru/zend.mail.smtp-authentication.html
и видим: "… на данный момент SMTP-аутентификация не поддерживается" :(
Что же делать?
Персональные блоги → OpenID запустил мобильный аутентификатор CallVerifID
MyOpenID запустил дополнительную возможность аутентификации пользователей с помощью телефона. Новый способ проверки подлинности называется CallVerifID и в ближайшем будущем может заменить используемые на данный момент токены, смарт-карты и сертификаты. CallVerifID использует сервис PhoneFactor — признанного лидера в организации безопасности и проверки подлинности с помощью телефона.
Базовый принцип работы сервиса CallVerifID индетичен работе любого провайдера OpenID и может работать с любыми провайдерами OpenID. Уровень безопасности myOpenID итак находится на высоком уровне, так как всегда запускается в безопасном режиме SSL.
Базовый принцип работы сервиса CallVerifID индетичен работе любого провайдера OpenID и может работать с любыми провайдерами OpenID. Уровень безопасности myOpenID итак находится на высоком уровне, так как всегда запускается в безопасном режиме SSL.