JEE6: Custom Realm vs ResourceFilter - какой из них лучше для проверки подлинности ресурса REST?

Question

У меня есть приложение JEE6, находящееся на Glassfish 3.1.1, которое предоставляет услуги удаленным клиентам через несколько ресурсов REST. Некоторые ресурсы требуют аутентификации, другие - нет.

В настоящее время я защищаю защищенные ресурсы с помощью HTTP Basic Authentication, реализованной как пользовательский realm/LoginModule. Если аутентификация не удалась, модуль входа в систему выдает карты LoginException, Glassfish, которые соответствуют HTTP 401. Если аутентификация прошла успешно, ресурсы могут получить доступ к userPrincipal в securityContext.

Хотя он работает, меня раздражает, что я не могу перехватить LoginException. Мои клиенты ожидают xml или json; в теле HTTP 401, Glassfish дает им текст/html. Все остальные исключения приложений я могу перехватить с помощью ExceptionMapper, а не с помощью исключения LoginException.

В настоящее время я думаю о замене пользовательского царства ResourceFilter, где я бы выполнил обычную проверку подлинности HTTP вручную. Я ожидал бы, что если я сделаю исключение здесь, он будет перехвачен и отображен/отображен должным образом.

Мои вопросы:

• Это хорошая идея использовать ResourceFilter для проверки подлинности? Как насчет производительности?
• Как я могу сообщить ресурсу REST, кто только что прошел проверку подлинности (кто является пользователем?)?

Answer 1

немного поздно, но все равно ...

Сво контейнер, который делает проверку подлинности, так что никогда не достигнет вашего ресурса. Лично мне нравится метод аутентификации, управляемый контейнером, потому что он прекрасно отделяет аутентификацию от приложения.

Если вы хотите использовать ResourceFilter, вы можете получить доступ к SecurityContext из запроса. Это содержит Принципала. Оттуда вы можете заполнить, например. объект ApplicationConfig, доступный во всем приложении.

Производительность зависит от реализации аутентификации. Я думаю, что накладные расходы при использовании ResourceFilter минимальны. При необходимости вы всегда можете использовать файл cookie сеанса, чтобы сеанс снова не позволял аутентификацию.