Доступ только для чтения к определенным зарегистрированным клиентам / Spring-MVC

Я знаю, что это кажется странным требованием, но когда клиент хочет, это означает, что у нас нет другого выбора. Я работаю над веб-приложением (E-Commerce), и мне нужно зарегистрировать нового клиента, до сих пор все работает отлично. Однако есть требование со следующими случаями

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

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

  1. добавить новую роль под spring security и для тех, кто имеет доступ только для чтения, должна быть эта новая роль.
  2. создать своего рода HandlerInterceptor который будет проверять роль клиента перед выполнением запроса.

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

  1. обновить его/ ее профиль
  2. пароль обновить.
  3. любое другое обновление там профиль
  4. Не позволяйте клиенту оформить заказ
  5. фактические цены со скидкой не должны быть видны
6
java java-ee spring spring-mvc

3 ответов

лучший подход-использовать простой механизм управления доступом на основе ролей (RBAC). Это хорошо поддерживается Spring Security и прост в использовании.

вы должны создать новую роль (например, "FULL_ACCESS") и назначить ее правильным пользователям на основе их адреса электронной почты. Роль должна охватывать пользователей с полным доступом, а не с правами только для чтения, как предлагалось в вашем вопросе.

вы обычно определяете роли для текущего пользователя в своей реализации из UserDetailsService. Вы можете использовать org.springframework.безопасность.ядро.власть.SimpleGrantedAuthority как ваша реализация GrantedAuthority (в вашем контексте GrantedAuthority это та же роль). GrantedAuthorities, возвращенные из вашего UserDetailsService, хранятся внутри объекта аутентификации вашего пользователя и доступны в течение срока действия сеанса пользователя.

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

после заполнения GrantedAuthorities вы можете использовать как декларативные, так и программные средства авторизации. Для программной авторизации (авторизация выполняется непосредственно в коде), например:

 if (request.isUserInRole("FULL_ACCESS")) {
      // Only for users with full acccess
 }

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

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

Spring Security также предоставляет набор aurhorization JSP теги что может помочь вам правильно сделать ваш пользовательский интерфейс для разные типы пользователей.

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

3

Мне нравится управление доступом на основе выражений spring-security для аннотирования методов контроллера с разрешенными ролями, но вместо этого вы можете использовать перехватчики url, если ваши действия легко отделимы по url и / или HTTP-глаголу. Любое решение должно помешать им выполнять любые действия, которые они не должны.

тогда вы также можете ограничить данные и / или ссылки, которые пользователь может видеть, просто указав другое представление, если им не хватает определенной роли (или используя spring security авторизовать тег в том же представлении).

2

Я бы пошел создавать новые роли и использовать spring-выражение безопасности на основе контроля доступа как предложено @peter-g.

если ваша электронная коммерция-это традиционное веб-приложение (серверные страницы), фильтрация URL-адресов-не лучший подход. В этом случае я бы объединил:

  1. аннотации уровня метода на уровне сервиса. Только @PreAuthorize аннотации, помещенные в вызов записи для bean, будут полезны. Если вы вызываете myService.methodA() и этот метод вызывает аннотированный метод this.methodB() (это myService()), аннотации безопасности не будут работать. Они будут работать только при первом вызове на myService (в этом случае размещены на methodA()). Это служит брандмауэром безопасности для вашей бизнес-логики.
  2. фильтрация ссылок/данных при рендеринге страниц на основе ролей. В JSPs отфильтруйте содержимое и ссылки (которые на самом деле являются действиями), не соответствующие текущим активным ролям. Это имеет две цели. Одно, показать специфическое содержание к специфическому роли. Во-вторых, это первый барьер безопасности, чтобы избежать доступа пользователя к вашей бизнес-логике. Вы даже не показываете им, что для них доступно конкретное действие.

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

если ваш сервер-это веб-API, вы можете использовать фильтрацию URL-адресов с аннотациями или конфигурацией XML/Java и фильтровать выходные данные с помощью представлений jackson (если вы используете JSON) или XSLT при использовании XML. Это позволяет более точное управление и более последовательного осуществления безопасности.

2