JAAS JBOSS 7 Авторизация и аутентификация толстого клиента

@Spondee · Регистрация: 14.10.2012

Студворк — интернет-сервис помощи студентам

Появилась такая задача.
Есть толстый клиент и JBOSS AS 7.
Необходимо логинить пользователей через толстый клиент.

Кто знает где можно почитать новичку в этом вопросе о том, как это делать правильно с участием JBOSS 7. Нужна доступная детальная дока. Или хотя бы последовательный список источников после прочтения которых все становится понятно. И если можно, вкратце обрисовать, как эти механизмы работают, какой уровень безопасности они предоставляют.

Большое спасибо!

@mutagen · 14.10.2012, 02:13

вкратце так http://www.coderanch.com/t/881... S-Tutorial

длиннее тут http://devbank.wordpress.com/2... ial-part1/

самое длинное http://www.oracle.com/technetw... 89689.html

@Spondee · 14.10.2012, 03:54 **[ТС]**

Спасибо за ссылки. Начинаю вникать.. По факту отпишусь.

@Spondee · 19.10.2012, 19:47 **[ТС]**

Вот что удалось накопать.

Аутентификаци на основе JAAS лучше всего расписана вот тут:
http://www.javaranch.com/journ... 804.jsp#a6

Делее специфика JBOSS 7.1
Покажу как наладить удаленный доступ к EJB компоненту, при этом обеспечить аутентификацию пользователей: понять кто именно вызывает наш EJB метод, а также как уметь ограничить доступ пользователей, либо ограничить доступ пользователей, которые не обладают необходимыми правами.

Подразумевается, что хотя бы поверхностно с JBOSS 7 и EJB 3 знакомы.

В standalone.xml

1. добавляем Realm, в раздел <management>
<security-realms> по аналогии с ApplicationRealm:

XML
1
2
3
4
5
            <security-realm name="MyRealm">
                <authentication>
                    <jaas name="ejb-security-domain"/>
                </authentication>
            </security-realm>

2. В разделе <subsystem xmlns="urn:jboss:domain:security:1.1"> <security-domains>
добавляем новый security domain:

XML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
                <security-domain name="ejb-security-domain" cache-type="default">
                    <authentication>
                        <login-module code="Remoting" flag="optional">
                            <module-option name="password-stacking" value="useFirstPass"/>
                        </login-module>
                        <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
                            <module-option name="defaultUsersProperties" value="${jboss.server.config.dir}/my-users.properties"/>
                            <module-option name="defaultRolesProperties" value="${jboss.server.config.dir}/my-roles.properties"/>
                            <module-option name="usersProperties" value="${jboss.server.config.dir}/my-users.properties"/>
                            <module-option name="rolesProperties" value="${jboss.server.config.dir}/my-roles.properties"/>
                            <module-option name="password-stacking" value="useFirstPass"/>
                        </login-module>
                    </authentication>
                </security-domain>

3. В разделе

XML
1
2
3
4
  <subsystem xmlns="urn:jboss:domain:remoting:1.1">
            меняем security realm на наш новый реалм:
         <connector name="remoting-connector" socket-binding="remoting" security-realm="MyRealm"/>
</subsystem>

Создаем файлы с пользователями и ролями, на которые будет опираться Логин модуль из рункта 2:
my-users.properties
my-roles.properties

Несмотря на то что в файле для создания пользователей для applicationRealm указано, что пароль должен быть хеш функцией с участием realm, так это не работает с другим реалмом. Да и не нужно.
Надо просто указать пароль без всякого хеширования
# The format of this realm is as follows: -
# username=HEX( MD5( username ':' realm ':' password))

пример (для my-users.properties):
userAlex=pass1234

пример (для my-roles.properties)
userAlex=admin,superuser,
(роли указываются через запятую, без каких либо пробелов и в конце тоже запятая!)

С настройками сервера все.

Серверная часть, EJB
В EJB никаких xml не надо (не обязательно, делаем все по-современному, через аннотации):
Тут легче объяснить на примере.

Пример.

Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@org.jboss.ejb3.annotation.SecurityDomain("ejb-security-domain")
@Stateless
public class ServerInfo implements ServerInfoRemote, Serializable {
 
    private static final long serialVersionUID = 1L;
    
    @Resource
    SessionContext session;
    
    @javax.annotation.security.RolesAllowed("uperuser")
    @Override
    public String getServerInfo() {
        Principal p = session.getCallerPrincipal();
        
        String s = "Server works. User/Executor/Principal = " + p.getName();
        
        return s;
    }
}

Так как вызов удаленный, то естественно, принимаемые и возвращаемые параметры должны быть сериализуемыми, и сам бин всеже тоже.

Аутентификация:
При удаленном вызове с клиента, когда мы попадаем в бин, в контексте сессии уже содержится пользователь, от имени которого с клиента происходит соединение.
Поэтому из контекста сессии мы узнаем что за пользователь выполняет метод.

Авторизация:
Контроль за выполнением проходит двумя способами.
1) Во-первых, к этому бину имеет право получить доступ только пользователь из security domain "ejb-security-domain", это обеспечивается аннотацией
SecurityDomain("ejb-security-domain") перед именем класса.
2) Метод getServerInfo() могут выполнять только пользователи, у которых есть роль (право) "uperuser".

Клиетская часть.

Так мы получаем InitialContext для удаленного доступа к нашим бинам (бину).

Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public static Context getInitialContext() throws javax.naming.NamingException {
String userName = "userAlex";
String userPass = "pass1234";
 
 
        Properties props = new Properties();
        props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
        props.put(Context.PROVIDER_URL, "remote://localhost:4447");
        props.put(Context.SECURITY_PRINCIPAL,  userName);
        props.put(Context.SECURITY_CREDENTIALS, userPass);
        props.put("jboss.naming.client.remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED","false");
        props.put("jboss.naming.client.ejb.context", true);
        props.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");
 
        return new InitialContext(props);
}

String userName = "userAlex";
String userPass = "pass1234";
Таким образом вы передаете данные пользователя, под которым хотите взаимодействовать с бином.

Context context = getInitialContext();

String earName="myejb"; // myejb.ear - то что задеплоено на сервер, где находится jar с бином
String jarName="servercode"; // servercode.jar - внутри ear находится jar файл, в котором наш ejb bean
String beanClassSimpleName; // ServerInfo
String beanClassName; // com.gp.ejb.ServerInfoRemote

ServerInfoRemote statelessBean = ServerInfoRemote context.lookup("myejb/servercode/ServerInfo!com.gp.ejb.ServerInfoRemote") ;

Эту же стороку можно увидеть, когда вы деплоите на сервер свой ear. В консоли JBoss при деплое выводит JNDI имена. Воспользоваться можно только одним, и то, определенным способом
Для данного примера AS7 выведет среди прочих:
java:jboss/exported/myejb/servercode/ServerInfo!com.gp.ejb.ServerInfoRemote

В общем случае, подойдет то, что после exported.

Таким образом мы получаем доступ (прокси) к нашему бину.
Далее вызовем удаленный метод:
String s = statelessBean.getServerInfo() // получим s= "Server works. User/Executor/Principal = userAlex"

Можно также подключать на сервере и другие LoginModules , например для аутентификации пользователей не из файла properties как в данном примере, а из базы данных (https://community.jboss.org/thread/168992)
к счастью информация на эту тему широко доступна.
Да, при изменении файла с пользователями, сервер сразу же подтягивает информацию из файла (как измененные пароли, новые пользователи или изменение ролей у пользователя), перезапускать не надо.

Можно также подключить SSL. В этом случае удаленное взаимодействие станет еще и безопасным. Но это уже отдельная песня.

Новые блоги и статьи Все статьи Все блоги /
сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .	Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .
Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .	Расчёт токов в цепи постоянного тока igorrr37 05.01.2026 / * Дана цепь постоянного тока с сопротивлениями и источниками (напряжения, ЭДС и тока). Найти токи и напряжения во всех элементах. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа и. . .

@Spondee 66 / 0 / 1 Регистрация: 14.10.2012 Сообщений: 3

	JAAS JBOSS 7 Авторизация и аутентификация толстого клиента 14.10.2012, 01:17. Показов 5241. Ответов 3 Метки нет (Все метки) Появилась такая задача. Есть толстый клиент и JBOSS AS 7. Необходимо логинить пользователей через толстый клиент. Кто знает где можно почитать новичку в этом вопросе о том, как это делать правильно с участием JBOSS 7. Нужна доступная детальная дока. Или хотя бы последовательный список источников после прочтения которых все становится понятно. И если можно, вкратце обрисовать, как эти механизмы работают, какой уровень безопасности они предоставляют. Большое спасибо! 0

@mutagen 2587 / 2260 / 257 Регистрация: 14.09.2011 Сообщений: 5,185 Записей в блоге: 18
	14.10.2012, 02:13
	вкратце так http://www.coderanch.com/t/881... S-Tutorial длиннее тут http://devbank.wordpress.com/2... ial-part1/ самое длинное http://www.oracle.com/technetw... 89689.html 2

@Spondee 66 / 0 / 1 Регистрация: 14.10.2012 Сообщений: 3
	14.10.2012, 03:54 [ТС]
	Спасибо за ссылки. Начинаю вникать.. По факту отпишусь. 0

JAAS JBOSS 7 Авторизация и аутентификация толстого клиента

Решение