Как обезопасить веб-сервисы на GlassFish 2? - PullRequest
Новая
       55

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

1 голос
/ 27 января 2011

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

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

Ответы [ 3 ]

5 голосов
/ 28 января 2011

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

@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 является тривиальным (консоль администратора).однако вы можете создать свой собственный пользовательский модуль и модуль входа в систему

3 голосов
/ 27 января 2011

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

Например, 

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

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

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

1 голос
/ 28 января 2011

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

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

...