Модель контроля доступа в JBoss.
Сильно не хочется зарываться в эту тему "по теории", но все-таки придеться немного написать, хотя бы в простейшем и неполном виде.
Как правило , под "контролем доступа" понимаются ДВА процесса.
Первый процесс - это идентификация (authentication) пользователя, который как правило происходит один раз при начале работы клиента с сервером/сервисом. Это означает, что производиться проверка, что "вы - это вы". Обычно используется самый распространенный способ - "имя + пароль", хотя можно использовать и более "замысловатые варианты", например сертификаты. При этом сервер проверяет, что он "знает" о пользователе с предоставленным именем, и проверяет совпадает ли введенный пароль (или не сам пароль, а ХЭШ значения сравниваемых паролей) с тем, который известен ему в системе.
Второй процесс - это авторизация (authorization) или проверка полномочий или прав доступа пользователя к каждому ресурсу. Этот процесс происходит каждый раз при обращении клиента к сервисам/ресурсам, например методам бинов, сервлетам, JSP, очередям JMS у JBoss-а. Суть этого процесса заключается в том, что сервер все время проверяет, имеет ли данный клиент права доступа, которые описаны как "необходимые и достаточные" для доступа к сервису. Существует два типа авторизации - "программная" и "декларативная".
Рассматривать программный способ я не буду, только кратко скажу о его сути. Суть программного метода заключается в том, что в методе бина программист должен написать код, который проверяет - достаточно ли у пользователя прав для вызова этого метода, т.е. мы сами должны написать код проверки и выполнить ее.
Смысл декларативной авторизации в том, что в файле-дескрипторе описываются необходимые для доступа "роли-права доступа " и все проверки выполняются самим сервером без нашего вмешательства.
Согласно J2EE спецификации, JBoss реализует "контроль доступа" к своему контейнеру (в первую очередь EJB-контейнеру, но и к другим контейнерам тоже), используя технологию JAAS. Эта технология позволяет на ее основе писать "свои" модули контроля доступа (логин-модули) и "встраивать" их в сервер "как плагины". Назначение "логин-модуля" - проверка идентификации пользователя и получение для указанного имени пользователя "ролей-прав", которые сервер "кэширует", ассоциируя их с security context-ом пользователя. Что такое "роли", которые я называю "роли-права доступа " - см. дальше.
Каждый вызов, каждое обращение любого клиента к ресурсам сервера - методу(ам) EJB, обращение к сервелету, обращение к JSP, JMS, происходит через "специальные" в JBoss-е объекты - "security interceptor". "Security interceptor" - это специальные прокси-объекты JBoss, обращение к которым происходит ДО того, как клиент получит доступ к ресурсу и именно в них выполняется авторизация клиента, т.е. проверяется "разрешение" на доступ. Это выполняется самим сервером, с помощью сравнения списка "ролей-прав" клиента, извлеченных и кэшированных при первом входе клиента в систему, со списком "ролей-прав" описанных для "ресурса", к которому выполняется обращение.
Возможно, вам НЕ придеться писать самостоятельно ни объекты "security interceptor", ни "логин-модули", т.к. сервер имеет уже несколько готовых модулей и вы просто воспользуетесь ими. Это может быть простейший способ на основе двух файлов users.properties + roles.properties. Есть и другие модули - на основе обращения к СУБД, есть с использованием LDAP сервера. Подойдут ли они вам и работают ли они так как требуется вам - решать и проверять только вам.
Итак, объекты "security interceptor" управляются некоторым объектом "security-manager", который для своей работы, использует подключенные JAAS логин-модули. Такой "логин-модуль" определяет некоторый способ получения и извлечения информации об пользователе, обычно: имя, пароль + права доступа (роли) к ресурсам/сервисам. Всю эту кухню (вместе с другими security объетками) принятно называть "доменами контроля доступа", security domain, security realm.
Если вы ранее ни разу НЕ устанавливали и НЕ настраивали security JBoss-е, то скорее всего оба этих процесса идентификации и авторизации, происходили и происходят у вас совершенно "прозрачно" и незаметно, вы возможно даже НЕ думали, что они вообще происходят. Но на самом деле все проверки выполняются, но правила для проверки "не применяется", потому что вы НЕ указали ни одного "домена контроля доступа" в вашем J2EE приложении.
