2015-03-07 3 views
0

У меня есть одно требование, чтобы программным образом добавить ограничение авторизации (полномочия) (это не аутентификация). У меня есть управляемый программой CDI управляемый bean-компонент следующим образом.Программируемая авторизация в JAAS

@Named 
@ApplicationScoped 
public class Bean { 
    @Inject 
    private Service service; 
    private List<Entity>list; 

    public Bean() {} 

    @PostConstruct 
    private void init() { 
     initialize(); 
    } 

    private void initialize() { 
     // Initialize the list on application start up. 
     // The service.getList() method in an EJB is authenticated anonymously 
     // for the first time on application start up. 
     list=service.getList(); 

     // Do something programmatically to enforce the authority ROLE_ADMIN afterwords. 
    } 

    // This method is only invoked by an admin (ROLE_ADMIN) as and when required. 
    // The @PostConstruct method may however be invoked by an anonymous user on start up. 
    public void action() { 
     initialize(); 
    } 
} 

Возможно ли принудительное исполнение полномочий/роли программно перед методом украшенной @PostConstruct отделки, так что метод service.getList() EJB вызывается только пользователем (ами), имеющим указанный ROLE_ADMIN орган после того, как метод украшен @PostConstruct заканчивает работу?

Другими словами, он ведет себя точно так, как показано ниже, после слов - один раз @PostConstruct заканчивает работу?

@Stateless 
@DeclareRoles(value = {"ROLE_ADMIN", "ROLE_USER"}) 
@RolesAllowed(value = {"ROLE_ADMIN"}) 
public class Skeleton implements Service { 

    @Override 
    public List<Entity> getList() { 
     return entityManager.createQuery("SELECT e FROM Entity e").getResultList(); 
    } 
} 

настоящее время я использую GlassFish Server 4.1, но было бы лучше, если ответ (ы) были контейнер агностик.

+0

Возможно [это поможет] (http://docs.oracle.com/javaee/7/tutorial/security-javaee002.htm#GJGCS) –

+0

Я не думаю, что это имеет смысл в контексте ' @ ApplicationScoped' bean. –

+0

@peeskillet: вся эта страница описывает использование '@ DeclareRoles',' @ RolesAllowed' и '@ RunAs'. Он ничего не говорит о назначении авторитета/роли динамически во время выполнения, то есть «* программно *». – Tiny

ответ

0

Я не уверен, что сработает, но вы можете попробовать следующее. Создайте EJB Bean, получая SessionContext, а затем используйте метод isCallerInRole (роль).

@Stateless 
public class AuthorizationBean { 
    @Resource 
    private SessionContext sessionContext; 

    public Boolean isCallerInRole(String role){ 
    return this.sessionContext.isCallerInRole(role); 
    } 
} 

Внесите этот компонент в свой класс, а затем проверьте роль. Проблема здесь в объеме своего класса (ApplicationScoped), поскольку это не обязательно, будет ли оно работать.

+0

Характер вопроса совершенно другой. Речь идет не о проверке полномочий пользователя или проверке полномочий. EJB, где находится метод 'getList()', аутентифицируется анонимно, когда он вызывается в первый раз, поскольку он вызывается при запуске приложения (из метода '@ PostConstruct', который вызывается только один раз для области приложения либо лениво или с нетерпением). Это приведет к сбою с исключением безопасности, если сам метод или соответствующий EJB присваивается роль/полномочия декларативно (с использованием '@RolesAllowed (value = {" ROLE_ADMIN "})'), и если он выполняется анонимно. – Tiny

+0

Дело в том, что полномочия 'ROLE_ADMIN' должны быть назначены непосредственно перед тем, как заканчивается метод' @ PostConstruct', так что методу или EJB может быть предоставлен авторитет 'ROLE_ADMIN', то есть метод EJB' getList() 'должен быть вызван анонимно в первый раз, когда загружается компонент области приложения, но ему должен быть предоставлен авторитет «ROLE_ADMIN» после этого и затем при каждом вызове этого метода, кроме первого вызова метода '@ PostConstruct'. Это очень особый случай и не нужен все время. – Tiny

+0

Кстати, эта проверка 'sessionContext.isCallerInRole (role); 'также может быть смоделирован на самом веб-слоте, если необходимо, используя' HttpServletRequest # isUserInRole ("ROLE_ADMIN") '. Нет необходимости использовать 'SessionContext' или' EjbContext', чтобы это было так на веб-уровне. – Tiny

Смежные вопросы