Использование JaaS с Джерси на Grizzly

Я пытаюсь найти простой и гибкий способ добавить аутентификацию JaaS в REST. Я нашелПочта я думаю, что ведет меня в правильном направлении (см. ответ StevenC). Похоже, за безопасность отвечает контейнер сервлетов, а не сам код Джерси. Мне нравится эта идея, но нужно небольшое руководство по реализации.

Grizzly - это мой контейнер сервлетов, и я хочу настроить его на использование JaaS для аутентификации. На данный момент, простая комбинация имя пользователя / пароль будет в порядке, а жесткое кодирование пар имя пользователя / пароль непосредственно в коде - хорошо. Пока он использует JaaS, мы можем уточнить эти детали позже.

Что касается того, что отправляется по HTTP, я думаю, что хранение куки будет самым простым способом заставить все это работать. Все, что нужно, чтобы уберечь аутентификацию от моего кода на Джерси.

Вот код для запуска Grizzly:


final String baseUri = "http://localhost:9998/";
final Map initParams = new HashMap();

initParams.put("com.sun.jersey.config.property.packages", 
  "my.jersey.Service");

System.out.println("Starting grizzly...");
SelectorThread threadSelector = GrizzlyWebContainerFactory.create(baseUri, initParams);
System.out.println(String.format(
        "Jersey app started with WADL available at %sapplication.wadl\n"
  + "Try out %shelloworld\nHit enter to stop it...", baseUri, baseUri));                
System.in.read();
threadSelector.stopEndpoint();
System.exit(0);

Если весь этот процесс работает, как лучше всего проверить права доступа для пользователя? Я, вероятно, хотел бы, чтобы мой код REST действительно проверял разрешения в определенных точках. Я даже на правильном пути? Есть ли более простой способ? Ссылка на учебник будет отличным ответом. Даже такой ответ, как «Я сделал это, и это сработало», дал бы мне теплую неясность, что я направляюсь в правильном направлении.

Спасибо за любую помощь.

РЕДАКТИРОВАТЬ: Некоторые разъяснения для комментария StevenC:

Вы все еще хотите использовать фильтры сервлетов для защиты своих ресурсов? Я буду использовать все, что может отделить детали аутентификации от кода Джерси. Это не должны быть фильтры сервлетов.Что означает «настроить его на использование JaaS»? Первоначальный план состоял в том, чтобы защитить текущий API с помощью JaaS. Следующим этапом будет сделать весь API доступным онлайн. Казалось, имеет смысл иметь оболочку Джерси вокруг вызовов API, но при этом аутентификация должна обрабатываться Grizzly. Я полагаю, что Grizzly должен будет взаимодействовать с JaaS.Вы думаете, что должен быть какой-то конфиг, который просто заставляет гризли защищать ваши ресурсы? Я рассматривал двухэтапный процесс аутентификации пользователя и на основе ролей, предоставляя пользователю доступ к ресурсам. Идея заключалась в том, чтобы Grizzly обрабатывал аутентификацию (используя JaaS) и авторизацию на Джерси.«Я не вижу необходимости использования файлов cookie с ресурсом RESTful». Было бы замечательно удалить использование куки, но как это сделать? Система должна знать, аутентифицирован ли пользователь. Я бы не стал просить их передавать имя пользователя / пароль / и т. Д. Для каждого звонка. Даже передача маркера сеанса в качестве параметра при каждом вызове кажется «уродливой».

Также обратите внимание, что я довольно новичок в REST. Я занимаюсь SOAP пару лет, поэтому у меня может быть «предвзятость SOAP», которая может ослепить меня из-за какого-то очевидного, простого решения, которое используют все. Если есть более простой способ, пожалуйста, не стесняйтесь поделиться. Я просто пытаюсь узнать как можно больше.

Ответы на вопрос(2)

Ваш ответ на вопрос