Предложения по реализации авторизации на основе ролей для существующего приложения во Flex - PullRequest
Новая
       10

Предложения по реализации авторизации на основе ролей для существующего приложения во Flex

0 голосов
/ 09 июля 2011

У меня есть приложение, которое написано с использованием Flex 3 на стороне пользовательского интерфейса и java @ уровня сервиса, а также BlazeDS.Теперь нам нужно авторизовать пользователей, обращающихся к системе, на основании ролей, определенных для них в базе данных, например: скажем, пользователь с ролью гостя не должен иметь доступа к вкладке «Администратор» в пользовательском интерфейсе, а также не может выполнять какие-либо действия.Операции, кроме просмотра данных, отображаемых на приборной панели. Также следует отметить, что роли могут динамически создаваться пользователями Super из пользовательского интерфейса.

Я натолкнулся на эту ссылку, которая описывает, как выполнить Role BasedАутентификация и авторизация

При таком подходе мне нужно определить роли в service-config.xml, но поскольку мои роли не определены заранее, я не могу пойти с этим.

Есть кто-нибудьстолкнулся с аналогичной ситуацией.Любые указатели будут очень полезны.

1 Ответ

3 голосов
/ 10 июля 2011

Да, мне тоже не нравится идея настройки службы, не виню вас.

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

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

  • Пользователям назначена одна или несколько ролей
  • Ролям назначено одно или несколько разрешений
  • Функциональные возможности защищенных разрешений

Итак, в вашем приложении вы определяете определенные разрешения - части приложения, которые зависят от безопасности - видимые / невидимые / могут или не могут выполняться, и т. Д. Как я обычно делаюсделать это с помощью строковой константы.Поэтому в ситуации с управлением заказами у меня могут быть CanCreateOrder, CanViewOrder, CanCancelOrder, CanFlagOrder.

. На стороне сервера роль будет связана с этими разрешениями.Допустим,

  • Администратор может сделать все
  • CustomerService может сделать просмотр, и отметить
  • Клиент может сделать просмотр

Так далееваш сервер, пользователь A, который является администратором, получает список всех разрешений, связанных с назначенными им ролями, поэтому сервер отправляет обратно строку, подобную этой CanCreateOrder,CanViewOrder,CanCancelOrder,CanFlagOrder

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

Затем при проверке видимости или доступа к отдельным элементам вы просто проверяетеэтот массив или строка значений.

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

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

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

Имеет смысл?

** Естественно, вы можете зашифровать обмен безопасности и отправить по SSL, гарантируя, что эта транзакция выходит за рамки обсуждения;)

...