Jaspic: обрабатывать доступ к незащищенному ресурсу

Question

Я изучаю JASPIC, я начинаю небольшой проект с нуля, чтобы исследовать его и как он ведет себя на Wildfly. Первый шаг - вызвать мой метод SAM validateRequest и вернуть содержимое незащищенного ресурса, страницу index.html. Ок, validateRequest вызывается. Я проверяю, установлено ли MessageInfojavax.security.auth.message.MessagePolicy.isMandatory значение false. Вот тяжелые времена. В моей первой попытке, если для свойства установлено значение false validateRequest возвращает AUTH_SUCCESS значение, но браузер возвращает 403. В моей второй попытке validateRequest возвращает null, браузер возвращается 200, но в нем нет данных в ответе (ничего о index.html). Что делать, чтобы правильно обрабатывать запросы сервлета? Вы можете найти источник here. Благодарю.

Answer 1

Что делать, чтобы правильно обрабатывать запросы сервлета?

Понимать и придерживаться соответствующих разделов specification. Для типичных сервлет-ориентированные ServerAuthModule (SAM), те:

• Общий обзор модели обработки на стороне сервера сообщения (точка 2, где validateRequest вызывается), при условии, согласно § 1.2.5 и § 2.1 .5.2. Более поздняя, ​​а также диаграмма состояний модели на стр. 25 (стр. 39 в PDF) имеют особое значение.
• Специализация профиля контейнера HTTP сервлета, приведенная в § 3.8.3.2, § 3.8.4 и § 3.9.

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

Возвращение SUCCESS из validateRequest

Всякий раз, когда validateRequest реализация вашего SAM является возвращение AuthStatus.SUCCESS (null является не опция), он должен общаться личность звонившего к (Servlet) выполнения предварительного к возврату, независимо от того, действительно ли вызывающий абонент был аутентифицирован или анонимен. Это может быть достигнуто путем обработки CallerPrincipalCallback и/или по меньшей мере одного GroupPrincipalCallback (можно назначить группы анонимному вызывающему абоненту) с помощью предоставленного времени выполнения CallbackHandler. Построение любого из этих обратных вызовов с помощью аргумента null Principal (имя) для среды выполнения означает, что вызывающий абонент должен считаться анонимным или что к нему не должны быть связаны никакие группы. Опять же, обратите внимание, что стандартное допущение анонимного вызывающего абонента не выполняется с помощью совместимой среды исполнения; это должно быть указано явно, иначе результат не определен.

Семантика SUCCESS является то, что запрос должен иметь возможность распространяться на (Servlet основе) службы конечной точки, тогда и только тогда группы- (ролевые) авторизации вызывающего абонента на основе успешно. Однако для авторизации время выполнения должно быть информировано о личности вызывающего абонента, поэтому требуемые обратные вызовы необходимы.

AuthStatus значения против HTTP Response Коды состояния

Отношения между ними может быть немного запутанным. Первые - это нейтральные по протоколу и, по существу, метки перехода состояния в модели обработки сообщений. В теории они ограничивают более поздние; на практике, так как многие компоненты и сам сервер приложений могут изменять статус ответа, рекомендуется назначить его самостоятельно, если вы не используете AuthStatus.SUCCESS/AuthStatus.SEND_SUCCESSvalidateRequest/secureResponse возвратные случаи.