Как контролировать доступ пользователей к REST ресурсам?

Question

[Viktor Koltcov]

В Java EE приложении есть пользователи (user) каждый пользователь может создавать документы (Document)

Доступ к документам осуществляется через JAX-RS.

Перед тем как пользователь получит доступ к документам ему надо войти в систему, после чего он может делать запросы вида example.com/documents и example.com/document/15 он должен получать доступ только к своим документам и ошибку если пытается получить/удалить/изменить чужой документ.

Как организовать вход в систему пользователей и проверку принадлежности документа пользователю при удалении/обновлении документов?

Answer 1

[Виктор Потапов]

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

если есть возможность, я бы глянул в сторону spring-ws и spring-security. они более или менее успешно пытаются предоставить для всего этого удобное апи. и работают почти из коробки. но я сомневаюсь в целесообразности.

Comments

[Viktor Koltcov]

Спасибо за ответ.

А как клиенту передавать токен на сервер не хотелось бы его писать в URL, что думаете если залогиненого пользователя хранить в @SessionScoped бине, какие могут быть проблемы?

Рассматривал JAAS для этих целей, но там можно контролировать доступ только к методам целиком, и нельзя сделать ограничение поэлементным в рамках одного метода, в spring-security аналогично?

[Виктор Потапов]

Viktor Koltcov: да, только метод целиком, иначе никак.

если подробно то я представляю себе это примерно так.

клиент ---> сервер
логин + мд5 пароля

клиент <--- сервер
токен (рандомно генерящаяся строка) + добавляет соответствие юзер-токен в мапу\сессию.

все последующие подключения производятся с помощью токена, не хотите в url - используйте post.

всю логику проверки можно запихнуть в аспект, обрабатывающий выполнение метода аннотированного, допустим, аннотацией @Secured.

Для аспектов можно использовать AspectJ

[Виктор Потапов]

ну это все если делать предельно красиво и хорошо, не прибегая к использованию сторонних библиотек, не понимаю только к чему вам нужно поэлементное ограничение, ведь если юзер делает запрос example.com/document/15 и не имеет доступа к документу 15 - вернуть ошибку, вот и вся недолга

[Viktor Koltcov]

Виктор:
> ведь если юзер делает запрос example.com/document/15 и не имеет доступа
> к документу 15 - вернуть ошибку, вот и вся

вернуть ошибку а не документ, в моем понимании, это и есть поэлементный доступ - access control list (спасибо Никита )
но проблема в том что это проверку свой документ и чужой надо будет написать в каждом методе обновления удаления изменения, это было первая идея решения, но не хочется копипастить.

[Виктор Потапов]

Viktor Koltcov: я же говорю. гляньте в сторону аспектов. если объяснить использование аспекта в вашем случае - вы создаете класс SecurityControlAspect в нем описываете логику проверки на доступ и ставите ему что бы он срабатывал при использовании методов, аннотированных аннотацией @Secured. Вешаете эту аннотацию на нужные вам методы и все. все работает. все защищается. Внутри аспекта вы получаете в свое распоряжение срез метода. т.е. до его выполнения, выполняете нужные проверки и в случае ошибки возвращаете ошибку.

[Виктор Потапов]

Viktor Koltcov: подробнее почитать об аспектах можно в гайдах по AspectJ

Приблизительно будет что то вроде этого

aspect
public class SecurityControlAspect{
@Around("@annotation(com.test.security.Secure)") // указываем точку среза
public Object traceMethod(ProceedingJoinPoint pjp) throws Throwable { //получаем срез метода
if(checkAccess()){
Object o = pjp.proceed(); // "выполняем" метод в случае успешной проверки
return o;
}else{
return error; //возвращаем ошибку если доступа нет
}
}
}

[Viktor Koltcov]

Про Aspect понял, спасибо

В JEE это называется перехватчики @Interceptors

[Виктор Потапов]

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

[Viktor Koltcov]

Виктор: я так понял это разные решения одной задачи. Принципиально они решают одну задачу, вроде.

Answer 2

[Никита]

Spring security access control list например
docs.spring.io/spring-security/site/docs/3.0.x/ref...

Comments

[Viktor Koltcov]

access control list - это как раз то что нужно, в JEE стеке есть API для этого, или только spring ?

[Никита]

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

[Viktor Koltcov]

Спасибо за помощь!

Answer 3

[jumb0jet]

Например ты можешь создать поле createdBy или owner, в котором будешь хранить пользователя который создал документ. И при попытке доступа к чужому документу возвращать статус 403.
Для того чтобы передавать данные о пользователе ты можешь использовать либо cookie либо в каждом запросе передавать username/password.

Comments

[Viktor Koltcov]

Спасибо за отчет.
Document и User конечно связаны, каждый user знает свои документы и каждый документ знает своего владельца.

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

Answer 4

[Вячеслав]

Вход пользователей в систему стоит делать через готовый фреймворк. Я использую Apache Shiro. Писать что-то своё для авторизации точно не стоит.

Проверку принадлежности документа пользователю можно сделать через идентификатор пользователя (PK в базе, например): при создании документа идентификатор пользователя записываете в документ, а при изменении/удалении документа сравниваете идентификатор текущего пользователя и идентификатор пользователя, сохранённый в документе. При использовании Shiro получить текущего пользователя не проблема.