Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

EJB security

1.0K
23 мая 2007 года
diesel_den
169 / / 22.12.2005
Прочёл две книжки по EJB 3.0.
В обоих есть раздел security.
В одной хорошо описана аутентификация
с помощью JNDI и авторизация с помощью
Java Annotation ролей.
В другой описаны технологии/протоколы (IIOP/SSL)
используемые для штфрования данных.
Но вот как это шифрование мне заюзать
в конкретном EJB ?
Мой случай - JDeveloper, Entity Beans from Tables
и созданные на их основе Session Beans.
Вот собственно работу с Session Beans
я и хочу обезопасить шифрованием.
1.0K
23 мая 2007 года
diesel_den
169 / / 22.12.2005
Я вот нашёл, что можно юзать аутентификацию
через логин/пароль для получения контекста.
И пароль можно шифровать SSL-ем.

Oracle8i Enterprise JavaBeans and CORBA Developer's Guide

Connecting Using JNDI
Before you can use JNDI to connect your client program to an Oracle8i server, you must set up an environment for the JNDI context. You can use a hash table or a properties list for the environment. The examples in this guide always use a Java Hashtable, as follows:

Hashtable environment = new Hashtable();

Next, you set up properties in the hash table. You must always set the Context URL_PKG_PREFIXES property. The remaining properties that you can set are for authentication. They are:

javax.naming.Context.SECURITY_PRINCIPAL

javax.naming.Context.SECURITY_CREDENTIALS

javax.naming.Context.SECURITY_ROLE

javax.naming.Context.SECURITY_AUTHENTICATION

These properties are described in the following sections.

URL_PKG_PREFIXES
Context.URL_PKG_PREFIXES holds the name of the environment property for specifying the list of package prefixes to use when loading in URL context factories. The value of the property should be a colon-separated list of package prefixes for the class name of the factory class that will create a URL context factory.

In the current implementation, this property must always be supplied in the Context environment, and it must be set to the String "oracle.aurora.jndi".

SECURITY_PRINCIPAL
Context.SECURITY_PRINCIPAL holds the database username.

SECURITY_CREDENTIALS
Context.SECURITY_CREDENTIAL holds the clear-text password. This is the Oracle database password for the SECURITY_PRINCIPAL (the database user). In all of the three authentication methods mentioned in SECURITY_AUTHENTICATION below, the password is encrypted when it is transmitted to the server.

SECURITY_ROLE
Context.SECURITY_ROLE holds the Oracle8i database role with which the user is connecting. For example, "CLERK" or "MANAGER".

SECURITY_AUTHENTICATION
Context.SECURITY_AUTHENTICATION holds the name of the environment property that specifies the type of authentication to use. Values for this property provide for the authentication types supported by Oracle8i. There are three possible values. These values are defined in the ServiceCtx class, and are:

ServiceCtx.NON_SSL_LOGIN: Authenticate using the Login protocol over a standard TCP/IP connection (not a secure socket layer connection). The Login protocol provides for encryption of the password as it is transmitted from the client to the server. See "The Login Protocol" for more information about this protocol.

ServiceCtx.SSL_CREDENTIAL: Authenticate using the credential protocol over a secure socket layer (SSL) connection. Encryption of the password is provided by the secure socket layer.

SSL_LOGIN: Authenticate using the Login protocol over an SSL connection. The extra encryption provided by the Login protocol is redundant in this case, and use of SSL_CREDENTIAL might be slightly more time efficient.

Note: To use an SSL connection, you must be able to access a listener that has an SSL port configured, and the listener must be able to redirect requests to an SSL-enabled dispatcher IIOP port. You must also include the library vbj30ssl.jar when you compile and build your application. See the Net8 Administrator's Guide for more information about configuration, and see EJB README file for information about the location of the vbj30ssl.jar file.

Context Methods
The Context interface contains a number of methods that the CORBA and EJB application developer will use. The methods required have been implemented in the ServiceCtx and SessionCtx classes that implement methods in the Context interface.

The JNDI InitialContext Class
InitialContext is a class in the javax.naming package that implements the Context interface. All naming operations are relative to a context. The initial context implements the Context interface and provides the starting point for resolution of names.

Constructor
You construct a new initial context using the constructor:

public InitialContext(Hashtable environment)


passing it a hashtable that has the environment information described in "Connecting Using JNDI" above. The following code fragment sets up an environment for a typical client, and creates a new initial context:

Hashtable env = new Hashtable();
env.put(Context.URL_PKG_PREFIXES, "oracle.aurora.jndi");
env.put(Context.SECURITY_PRINCIPAL, "scott");
env.put(Context.SECURITY_CREDENTIALS, "tiger");
env.put(Context.SECURITY_AUTHENTICATION, ServiceCtx.NON_SSL_LOGIN);
Context ic = new InitialContext(env);

Method
The most common initial context class method that the CORBA or EJB application developer will use is

public Object lookup(String URL)


You use lookup() to create a new service context, specifying in the URL the service identifier. The return result must be cast to ServiceCtx when a new service context is being created. For example, if initContext is a JNDI initial context, the following statement creates a new service context:

ServiceCtx service =
(ServiceCtx) initContext.lookup("sess_iiop://localhost:2481:ORCL");
1.0K
24 мая 2007 года
diesel_den
169 / / 22.12.2005
Мне нужно шифровать весь EJB-трафик, а не только
момент аутентификации.
Поэтому я планирую применить такое решение,
как ssh-port forwarding c логином и паролем,
который будет периодически меняться.
1.0K
27 мая 2007 года
diesel_den
169 / / 22.12.2005
Цитата: diesel_den
Мне нужно шифровать весь EJB-трафик, а не только
момент аутентификации.
Поэтому я планирую применить такое решение,
как ssh-port forwarding c логином и паролем,
который будет периодически меняться.



И всё равно это не годится,
потому как хакер может прикинуться серваком,
к которому я буду коннектиться, выдать мне открытый ключ,
я им зашифрую свой логин/пароль и он его спокойно
расшифрует своим закрытым. А потом прикинувшись
клиентом, передаст эти логин/пароль.

Мне нужен драйвер/утилита, которая
шифрует сетевой траффик закрытым ключом !!!

6.6K
27 мая 2007 года
Aoli
185 / / 22.01.2007
Простите, что прерываю Ваш монолог, но обратите внимание на такие штуки, как:
ldap/java.naming.security.protocol
&&
ldap/java.naming.security.authentication (про который Вы писали во 2ой части Вашего монолога)
6.6K
27 мая 2007 года
Aoli
185 / / 22.01.2007
И вдогонку:
Если уж совсем заморачиваться на безопасности, то можно в ejb-jar.xml для каждого метода бина прописать свою юзерскую роль.
1.0K
27 мая 2007 года
diesel_den
169 / / 22.12.2005
Цитата: Aoli
Простите, что прерываю Ваш монолог, но обратите внимание на такие штуки, как:
ldap/java.naming.security.protocol
&&
ldap/java.naming.security.authentication (про который Вы писали во 2ой части Вашего монолога)


Если я правильно понял это даёт защиту только
при получении ссылки на удалённый Session-bean.
Дальше работа с ним не шифруется : (
И если я правильно понял, то в качастве значения
java.naming.security.protocol по-умолчанию возможно только ssl -
то есть речь идёт об открытом ключе ?

1.0K
27 мая 2007 года
diesel_den
169 / / 22.12.2005
Цитата: Aoli
И вдогонку:
Если уж совсем заморачиваться на безопасности, то можно в ejb-jar.xml для каждого метода бина прописать свою юзерскую роль.


Это я прекрасно понимаю.
Мне от этих ролей не холодно - не жарко.

1.0K
27 мая 2007 года
diesel_den
169 / / 22.12.2005
Цитата: diesel_den
Если я правильно понял это даёт защиту только
при получении ссылки на удалённый Session-bean.
Дальше работа с ним не шифруется : (


А можно ли как-то переопределить/расширить класс,
отвечающий за передачу вызовов к Session-bean по сети,
чтобы самому реализовать шифрование этого траффика ?

6.6K
28 мая 2007 года
Aoli
185 / / 22.01.2007
Цитата:

ldap/java.naming.security.protocol...
Если я правильно понял это даёт защиту только
при получении ссылки на удалённый Session-bean.
Дальше работа с ним не шифруется : (


Про ldap/java.naming.security.protocol: http://java.sun.com/products/jndi/tutorial/beyond/misc/security.html
Про SSL: TLS involves three basic phases:
Peer negotiation for algorithm support
Public key encryption -based key exchange and certificate-based authentication
Symmetric cipher -based traffic encryption
(C) http://en.wikipedia.org/wiki/Secure_Sockets_Layer#How_it_works

Цитата:
ssl - то есть речь идёт об открытом ключе


Именно так. Т.к. закрытым ключом не имеет смысла шифровать. Ибо тогда клиент не расшифрует полученные данные, если у него нет ключа. А EJB аздуманы, как вэб-сервис, к которому могут подключаться клиенты, имеющие на то права. Таким образом, использование закрытого ключа имхо незачем реализовывать. Так, по-моему, это и не реализовано.

Цитата:

А можно ли как-то переопределить/расширить класс,
отвечающий за передачу вызовов к Session-bean по сети,
чтобы самому реализовать шифрование этого траффика ?


Можно шифровать не вызовы, а данные, проходящие через эти вызовы.
Например, перед вызовом метода бина setPassword(password), зашифровать password закрытым ключом.
А внутри бина уже расшифровать password.
Тогда у злоумышленника будет код вызова с зашифрованными данными.
А возможность переопределить/расширить класс,
отвечающий за передачу вызовов к Session-bean по сети - - хорошая идея, но вряд-ли sun "разрешит", т.к. это вобщем-то удар по безопасности.

1.0K
29 мая 2007 года
diesel_den
169 / / 22.12.2005
Цитата: Aoli

Про ldap/java.naming.security.protocol: http://java.sun.com/products/jndi/tutorial/beyond/misc/security.html
Про SSL: TLS involves three basic phases:
Peer negotiation for algorithm support
Public key encryption -based key exchange and certificate-based authentication
Symmetric cipher -based traffic encryption
(C) http://en.wikipedia.org/wiki/Secure_Sockets_Layer#How_it_works


Ну и что, что тут написано traffic encryption ?
Это ведь про сам SSL, а не про данный случай.
Принцип работы SSL я давно изучил : )
Как раз по логике java.naming.security.protocol
является протоколом, который используется только
java.naming, а не всем EJB. Иначе бы его
не запихнули в пакет java.naming.security.

Цитата: Aoli

Именно так. Т.к. закрытым ключом не имеет смысла шифровать. Ибо тогда клиент не расшифрует полученные данные, если у него нет ключа. А EJB аздуманы, как вэб-сервис, к которому могут подключаться клиенты, имеющие на то права. Таким образом, использование закрытого ключа имхо незачем реализовывать. Так, по-моему, это и не реализовано.


Как раз открытым ключом шифровать тут опасно.
Хакер, прослушав открытый ключ и имея зашифрованый пакет
за относительно небольшое время при наличии мощной ЭВМ
может расшифровать сообщение.
Из него он извлекает логин/пароль
и теперь он спокойно коннектится к серверу.
Если же юзать закрытые ключи и достаточно часто их менять,
то хакер просто не будет успевать их подбирать.
P.S.: В моём случае один EJB-клиент и несколько EJB-серверов.
Имеется возможность периодически всё это админить,
то есть ключи можно копировать не по сети, а на дискетке носить : )

Цитата: Aoli

Можно шифровать не вызовы, а данные, проходящие через эти вызовы.
Например, перед вызовом метода бина setPassword(password), зашифровать password закрытым ключом.
А внутри бина уже расшифровать password.


не хотелось бы так мудрить : )

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог