Веб-сервис JAX-WS и @rolesAllowed - PullRequest
       32

Веб-сервис JAX-WS и @rolesAllowed

6 голосов
/ 31 января 2012

Можно ли использовать @RolesAllowed аннотацию в веб-сервисе JAX-WS и если да, то как?

У меня есть веб-служба Glassfish 3.1.1, использующая базовую аутентификацию, но ограничения, выраженные с помощью @RolesAllowed, игнорируются. Информация о роли должна быть доступна, так как я могу получить к ней доступ следующим образом:

@Resource
WebServiceContext wsContext;

if (wsContext.isUserInRole("READ"))
log.info("Role: READ");

Я получаю ожидаемую роль, но все методы доступны, даже если для @RolesAllowed установлена ​​другая роль. @DenyAll тоже не работает.

Если эти аннотации не поддерживаются, возможно ли использовать дескрипторы развертывания для управления доступом к методам веб-сервиса на основе ролей пользователей?

Редактировать : Эта часть руководства по JAVA EE 6 описывает использование аннотации @RolesAllowed. Читается

Для компонентов Java EE вы определяете роли безопасности с помощью аннотаций метаданных @DeclareRoles и @RolesAllowed.

Веб-службы не перечислены в качестве компонентов Java EE в первой части руководства, поэтому, похоже, что аннотации безопасности не поддерживаются.

Edit2 После поста Изана я дал еще одну попытку. Вот что я сделал:

@Webservice
@DeclareRoles(value = {"READ", "UPDATE", "DELETE"})
public class ServiceImpl implements Service {
  @Override
  @WebMethod(operationName = "helloWorld")
  @RolesAllowed({"NONE"})
  public String helloWorld() throws Exception {
     return "Hello World!";
  }
}

Используя этот вид настройки, каждый может получить доступ к методу, независимо от того, какие роли установлены. Пользователи проходят аутентификацию (это можно увидеть в audit.log), но авторизация не происходит. Как указано выше, я могу получить доступ к роли из WebServiceContext (на самом деле я авторизую вручную, используя эту информацию).

Добавление аннотации @Stateless позволяет мне использовать аннотации безопасности. Так что @permitAll работает как положено. Но использование ролей по-прежнему не работает, поскольку пользователь не проходит проверку подлинности. Они отображаются как ANONYMOUS в журнале аудита и доступ к ним запрещен.

Мой web.xml выглядит так:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
 <display-name>OneMore</display-name>

 <security-constraint>  
    <display-name>WebServiceSecurity</display-name>  

    <web-resource-collection>  
      <web-resource-name>Authorized users only</web-resource-name>  
      <url-pattern>/service</url-pattern>  
      <http-method>POST</http-method>
    </web-resource-collection>  

    <auth-constraint>       
       <role-name>READ</role-name>
       <role-name>UPDATE</role-name>
       <role-name>DELETE</role-name>
    </auth-constraint>  

 </security-constraint>  

 <login-config>
    <auth-method>BASIC</auth-method>
 </login-config>

 <security-role>
    <role-name>READ</role-name>
 </security-role>

 <security-role>
    <role-name>UPDATE</role-name>
 </security-role>

 <security-role>
    <role-name>DELETE</role-name>
 </security-role>
</web-app>

Glassfish-web.xml просто сопоставляет имена ролей с именами групп, например:

<security-role-mapping>
   <role-name>READ</role-name>
   <group-name>READ</group-name>
</security-role-mapping>

Редактировать 3 Благодаря Изану и бесчисленным попыткам позже я, наконец-то, заработал.

Как уже было сказано, основным моментом было переключение с простого веб-сервиса на веб-сервис EJB путем добавления аннотации @Stateless. Это позволяет использовать аннотации безопасности.

Это изменение требуется также для изменения дескрипторов развертывания. В то время как исходный веб-сервис требовал glassfish-web.xml для настройки ролей, впоследствии потребуется glassfish-ejb-jar.xml.

Ответы [ 2 ]

6 голосов
/ 02 марта 2012

Может быть, это довольно тупой вопрос, но являются ли ваши веб-сервисы EJB-компонентами? Как отмечено в Аннотации безопасности и авторизация в GlassFish и Java EE 5 SDK

Аннотации @PermitAll, @DenyAll и @RolesAllowed определены для указания разрешений бизнес-метода EJB

Я использую эти аннотации с восходящим WS от EJB без сохранения состояния, и они работают как шарм в JBoss.


РЕДАКТИРОВАТЬ 1 @TPete Я добавлю немного кода, чтобы показать вам более или менее то, что я делаю.

@Stateless
@WebService()
@WebContext(contextRoot = WSContextRoot.CTX_ROOT, 
    authMethod = "BASIC")
@EndpointConfig(configName = "Standard WSSecurity Endpoint")
@SecurityDomain(value = "myDeclaredDomain")
@RolesAllowed({ "AUTHORISED" })
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT)
public class MyWS implements MyInterface {
    @Override
    public void doSomething(){
        //impl
    }
}

А что касается интерфейса

@Remote
@WebService
public interface MyInterface {

    @WebMethod(operationName="doSomething")
    public void doSomething(); 
}

WebContext, EndpointConfig и SecurityDomain являются аннотацией JBoss, но я предполагаю, что есть что-то похожее для GlassFish или эквивалентный способ сделать это. Домен безопасности включен в дескриптор развертывания для jboss и определен в файле login-config.xml из файлов конфигурации JBoss.


РЕДАКТИРОВАТЬ 2 @TPete

Полагаю, вам нужно добавить некоторые дескрипторы развертывания EJB из Glassfish, файл sun-ejb-jar.xml внутри вашего EAR. Опять же, из той же статьи, что и в ответе, есть Использование дескрипторов развертывания глава, в которой говорится

Для конечных точек веб-службы EJB с @RolesAllowed необходимо указать тип используемой аутентификации, указав элементы и в sun-ejb-jar. XML . Для аутентификации по имени пользователя и паролю установите элемент на BASIC, как показано в следующем примере. Этот шаг требуется только для конечных точек веб-службы EJB и не требуется для EJB.

Поскольку вы определяете конечную точку веб-службы EJB, я думаю, вам следует добавить этот дескриптор в ваш EAR. Взгляните на эту статью, она довольно хорошо описывает процесс, которому вы следуете: -)

0 голосов
/ 11 ноября 2013

Первоначальный вопрос старый, но я все еще оставляю комментарий на тот случай, если кто-то вроде меня наткнется на него. Начиная с EJB 3.1, EJB могут быть упакованы в модуль WAR, но когда речь идет об их защите, необходимо использовать дескрипторы развертывания EJB. В спецификации неясно, что EJB не могут быть объявлены сервлетами в web.xml, иначе приложение не запустится.

Вот отличная статья об упаковке EJB в модули WAR и о различиях с упаковкой в ​​модулях EJB JAR: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Finfo%2Fae%2Fae%2Fcejb_ejbinwar.html

...