Как защитить веб-сервисы на GlassFish 2?

Question

У нас есть несколько устаревших EJB-компонентов (EJB3), развернутых на сервере GlassFish 2, которые предоставляют некоторые из своих методов в качестве веб-сервисов через аннотацию @Webmethod.

Теперь мы хотим защитить эти методы веб-сервиса, чтобы его могли вызывать только аутентифицированные клиенты. Что было бы хорошим способом достичь этого?

Answer 1

Как сказал хороший преподобный. В приведенном ниже примере для проверки подлинности используется файловая область.

@Stateless
@WebService(name = "MyAppServices")
@RolesAllowed({"user"})
public class ItemEJB {
    ...
}

Вам также понадобится sun-ejb-jar.xml, например

<sun-ejb-jar>
<security-role-mapping>
            <!-- as defined in @RolesAllowed -->
    <role-name>user</role-name>
            <!-- glassfish group created in file realm -->
    <group-name>user</group-name>
</security-role-mapping>
<enterprise-beans>
    <ejb>
        <ejb-name>ItemEJB</ejb-name>
        <webservice-endpoint>
            <!-- equivalent to name attribute of @WebService -->
            <port-component-name>MyAppServices</port-component-name>
            <login-config>
                <auth-method>BASIC</auth-method>
                <realm>file</realm>
            </login-config>
        </webservice-endpoint>
    </ejb>
</enterprise-beans>

Создание группы в файловой области Glassfish является тривиальным (консоль администратора). однако вы можете создать свой собственный пользовательский модуль и модуль входа

Answer 2

Вы можете авторизовать список ролей для доступа к методу или целому бину, используя аннотации безопасности:

Например

@Stateless
@RolesAllowed({"user", "employee", "admin"})
public class ItemEJB {
    ...
}

Смотрите ссылку ниже для получения дополнительной информации:

http://java.sun.com/developer/technicalArticles/J2EE/security_annotation/

Answer 3

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

Я предполагаю, что это не связано с ССЛ. Так:
1) Клиент входит в систему с указанием имени пользователя и пароля
2) Если имя пользователя и пароль верны (хранятся в БД), то пользователь считается вошедшим в систему, и в ответе веб-сервис генерирует уникальный маркер сеанса (так или иначе связанный с именем пользователя и паролем) и отправляет его обратно в Ответить.
Этот токен хранится вместе с меткой времени, именем пользователя и паролем.
3) Каждый раз, когда клиент отправляет запрос, токен отправляется обратно вместе с другими параметрами. Если токен действителен, это означает, что запрос поступил от аутентифицированного клиента.
4) Все запросы должны иметь токен сеанса с остальными параметрами.
Таким образом, клиент без аутентификации не будет иметь токена для отправки.