Ок. Те получение InitialContext - это не дорогостоящая операция.
А еще подскажите плиз как правильно в таком варианте использовать секьюрити. Попробую объяснить мою проблему на этом же примере.
Те, сессион бин UserLogonImpl использует анатации, регламентирующие доступ к его методам согласно ролям:
1.
2.
3.
4.
5.
6.
7.
8.
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class UserLogonImpl implements UserLogon {
@RolesAllowed({"ADMIN, BACKUP"})
public Long logon() {
return 1L;
}
Пользователь
use_admin\admin_password принадлежит роли
ADMIN
Те для пользователя
use_admin\admin_password я использую такой вызов:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
....
Properties properties = new Properties();
properties.setProperty("java.naming.factory.initial","org.jnp.interfaces.NamingContextFactory");
properties.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.security.jndi.JndiLoginInitialContextFactory");
properties.setProperty("java.naming.factory.url.pkgs","org.jboss.naming:org.jnp.interfaces");
properties.setProperty("java.naming.provider.url", "localhost:1099");
properties.setProperty(Context.SECURITY_PRINCIPAL, "user_admin");
properties.setProperty(Context.SECURITY_CREDENTIALS, "admin_password");
Context context = new InitialContext(properties);
UserLogon userLogon = (UserLogon) context.lookup("UserLogonImpl/remote");
....
Здесь в InitialContext надо передавать
properties.setProperty(Context.SECURITY_PRINCIPAL, "user_admin");
properties.setProperty(Context.SECURITY_CREDENTIALS, "admin_password");
чтобы знать какой роли принадлежит пользователь и соответственно к каким медом ему разрешен
Аналогично для других пользователей. Те здесь мне приходиться явно в коде забивать Context.SECURITY_PRINCIPAL, Context.SECURITY_CREDENTIALS в properties прежде чем создать InitialContext и я не могу использовать jndi.properties. Может есть более красивое решение ?
