Некоторое время мне было интересно, можно ли использовать LDAP для управления привилегиями пользователей. Например, если у меня есть UNIX и веб-логины, есть ли простой способ предоставить пользователю доступ к просто или просто UNIX (или даже оба?)
Моя текущая попытка решить эту проблему заключалась в создании групп «входа в систему» и «без входа в систему», но это не кажется достаточно детализированным, чтобы соответствовать идеям, которые у меня в голове. Я также все еще нахожусь в ситуации, когда все пользователи UNIX являются веб-пользователями, что не столько проблема, сколько индикатор ограничений.
Есть ли у кого-нибудь мнения по этому поводу? Эта проблема уже решена?
Вы можете контролировать доступ несколькими способами. RBAC - это безопасность на основе ролей. Группы - это группы пользователей, а роли - это группы прав доступа. Вы можете отображать группы в роли или пользователей в роли. В этом случае ваши правила доступа могут выглядеть так:
«Разрешить всем в HR видеть базу данных HR», при реализации которой пользователи будут группироваться в объект LDAP groupOfUniqueNames. Обычно это приводит к более чистой организации, и большинство организаций стремятся к RBAC, начиная с нуля. Другой вопрос, является ли RBAC детализированным. Например, роли будут управлять доступом ко всему документу на основе групп, но не будут различать вас вплоть до уровня абзаца. Для некоторых организаций это крупнозернистый.
Более простой подход, если это звучит слишком сложно, - это использовать ABAC (безопасность на основе атрибутов), где ваше приложение / средний уровень / все, что контролирует доступ с помощью запросов LDAP, которые выглядят следующим образом: «Если у вас есть атрибут 'foo', вы можете нажать приложение foo. " или «Если ваш атрибут foo имеет значение HR, вы можете нажать на приложение HR».
Проблема с ABAC в том, что он превращается в настоящий беспорядок. Но для некоторых вещей это простая проверка. Например, я мог бы захотеть, чтобы люди с атрибутами uid, userPassword и mail были допущены в веб-приложение, потому что это обязательные атрибуты, которые нужны моему приложению. Затем мое приложение может искать роли и принимать более точные решения. Логин и логин - это действительно запросы (login=*) and (!(login=*)) который разрешил бы доступ на основе существования единственного атрибута. Это ABAC, и обычно его нельзя использовать повторно, и / или крайние сценарии убивают дизайн. В качестве надуманного примера: что, если у меня есть системный логин для работы cron, но я действительно не хочу, чтобы эта системная учетная запись входила в мое приложение. Если я установил nologin (например, shell в / dev / null или аналогичный), тогда мое задание cron не будет запущено, если я установлю его для входа в систему, мое задание cron будет запущено, но теперь системная учетная запись имеет возможность без необходимости входить в мое приложение. Создайте две роли (назовите их пользователями и системными учетными записями, как угодно), а затем создайте политику, удовлетворяющую обоим требованиям.
В масштабе предприятия организации используют продукты управления идентификацией (IDM) для централизованного управления, отчетности и автоматизации этих политик доступа. Автоматизация и отчетность пригодятся, когда у вас есть N систем в N подчиненных организациях в большой компании / организации.
Вы можете обрабатывать авторизацию в зависимости от базового сервера, который вы читаете через LDAP.
Например, в eDirectory вы можете указать объект с атрибутами, из которых пользователи, имеющие доступ, могут считывать конкретное значение атрибута.
Затем вы используете списки управления доступом eDirectory, чтобы разрешить или запретить это.
Используйте собственную модель ACL, и тогда вы сможете легко решить, есть ли у пользователя достаточные права через LDAP.
Я сделал это двумя разными способами и даже использовал оба одновременно. Во-первых, вы можете создавать для людей разные объектные классы, но это может стать проблемой. Другой способ - создать groupOfNames с каждым участником. Я использовал эти две вещи в сочетании, чтобы предоставить людям доступ к машинам UNIX через их ObjectClass, а затем детализированный контроль над различными веб-приложениями через groupOfNames.
В конечном итоге вам нужен способ отличить одну группу пользователей от другой, и при использовании LDAP / unix у вас есть два варианта: иметь запрос LDAP, который различает (& (userName = konrads) (unixLogin = yes)), или с помощью методов pam_ * распознавать локально.
Мне пришлось сделать что-то подобное только один раз, и мы добавили атрибут в нашу локальную схему и присвоили значение каждой системе, в которую пользователю разрешено входить.
Затем в конфигурации pam мы включили строку поиска, чтобы у них был этот атрибут, установленный соответствующим образом для этой машины, поэтому у вас может быть что-то вроде:
(&(host:acad1)( ... test to make sure they weren't disabled ... ))
Поскольку «хост» был многозначным, мы могли просто назначить пользователям столько хостов, сколько необходимо (и мы назначили uidNumbers выше 5000 для учетных записей LDAP, зарезервировав те, которые меньше 5000 для приложений, системных администраторов и других локальных учетных записей).