12 октября 2009 г. 15:13 пользователь Paul Wolneykien <mano...@altlinux.org> написал: > > Всем привет, > > В ходе обсуждения текущего состояния модулей alterator-openldap и > alterator-ldap-users, у нас с Димой (dkr@) возник вопрос о том, каким > вообще должно быть правильное построение авторизации управляющего модуля > в управляемые службы? >
Давайте уточним вопрос о том, что мы называем авторизацией, а что аутентификацией? В Unix (как впрочем также во многих других системах), насколько я себе представляю, авторизационные данные обычно открыты. Нет ничего страшного, если кто-то узнает о том, что данному имени пользователя соответствуют uid, gid, shell, etc... Процесс выяснения кому, что можно называют авторизацией. Это информация может быть сокрыта в недрах сервиса к, которому обращаются, а может быть указана в открытых источниках, например, сетевых группах, когда производится авторизация на основе групп. > Первый аргумент состоит в том, что управляемая служба вовсе не > обязательно находится на том же узле, что и Альтератор. Например, служба > LDAP, фактически, предназначена для того, чтобы управлять данными именно > по сети. Нужно только знать пароль. > > Второй аргумент состоит в том, что некрасиво спрашивать у > администратора пароль при совершении каждой операции с каждой службой. > Вполне достаточно того, что пароль требуется для доступа к самому > "Центру управления системой", т.е. альтератору. > Знать пароль и уметь обращаться от своего имени к любой службе - это отдельная задача. Это аутентификация. Обычно принято привязывать аутентификационные данные к авторизационным по именам (например, имя пользователя в LDAP и имя принципала в Kerberos). То есть сначала выясняем, что к нам обратился пользователь с именем vasya, а потом узнаём, что vasya - это Василий Пупкин, uid такой-то, состоит в таких-то группах. > В связи с этим, полагаю логичным задуматься об организации некоторого > механизма единой авторизации пользователя-администратора для управления > всеми доступными ему службами, такими как ldap, mysql и т.д. > Если я правильно понял, то вы имеете в виду единый механизм аутентификации. Такой механизм существует. Он называется Kerberos. Разработан он в MIT и уже давно активно используется. В частности, на нём построена и Microsoft Active Directory, которая и является, по сути, системой управления сетевыми сервисами. В принципе, Kerberos можно использовать и отдельно от единого механизма авторизации (LDAP, MySQL, etc). Например, именно так его используют в простых решениях описанных в документации по безопасности для FreeBSD. Последняя, конечно, не является примером для подражания, но, как пример, посмотрите. > Первый вопрос: делались ли уже подобные попытки? К примеру, не так > давно шла речь о переводе Альтератора на распределённые рельсы, для > управления кластером. Может быть эта модернизация позволит решить и > проблему единой авторизации? > Для таких попыток необходимо продумать механизмы единой аутентификации. Для альтератора, управляемого через web-интерфейс, это представляет собой отдельный, не тривиальный, но решаемый, вопрос. > Второй вопрос: может быть кому-то известно, как эта задача решена в > других дистрибутивах? > Вопрос в том, как решена... Полностью она решена только в крупных решениях вроде Novell eDirectory. Основными попытками сделать что-то подобное являются - Samba4 и FreeIPA. Последняя наиболее близка к тому, что вы хотите. Кроме того, подобную же задачу планируется (когда-нибудь) решить и в рамках проекта Tartarus. Можете прочесть наши с Димой (rlz@) статьи на этот счёт в тезисах 5 конференции в Обнинске. PS: Кстати, чтобы собрать freeipa нужна новая Samba, вернее новые либы от неё. А этот вопрос уже как бы обсуждался... Собственно для отдельного подпроекта - sssd, от freeipa, мне и были нужны эти либы и новая самба. Ну, и саму freeipa я собирался собрать... PPS: В общем, альтератор, насколько я понимаю, пока архитектурно не готов для такого рода решений. Но, вероятно, можно найти механизмы и как-то их приспособить, чтобы добиться удовлетворительного результата. -- Sin (Sinelnikov Evgeny) _______________________________________________ devel-conf mailing list devel-conf@lists.altlinux.org https://lists.altlinux.org/mailman/listinfo/devel-conf
