Как поставщик JACC может использовать средства сопоставления принципала и роли сервера, на котором он развернут?

154

Я пишу JACCпровайдеру.

Попутно это означает реализацию PolicyConfiguration.

PolicyConfigurationОтвечают за прием информации о конфигурации от сервера приложений, например, какие права начислять какие роли. Это сделано для того, чтобы Policyвпоследствии можно было принимать решения об авторизации при передаче информации о текущем пользователе и о том, что он пытается сделать.

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

Обычно - всегда, действительно - сервер приложений содержит это отображение. Например, на Glassfish, вы влияете это отображение, поставляя такие вещи , как sun-web.xmlи sun-ejb-jar.xmlи так далее с модулями Java EE. (Эти файлы, относящиеся к конкретному поставщику, отвечают за то, что, например, superusersэто группа, которой должна быть назначена роль приложения admins.)

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

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

Мой вопрос: как мне получить эту информацию о сопоставлении главных ролей в - для начала - Glassfish и JBoss изнутри PolicyConfiguration? Если есть стандартный способ сделать это, о котором я не знаю, я весь в ушах.

security jakarta-ee glassfish authorization jacc Лейрд Нельсон
источник
7
Достигли ли вы прогресса в этом вопросе? Я бы тоже хотел написать провайдера JACC, а также провайдера аутентификации JASPIC для создания портативных веб-приложений ...
perissf
Это также не кажется многообещающим: Because JSR-115 does not define how to address role mapping, WebLogic JACC classes are used for role-to-principal mapping.см. Docs.oracle.com/cd/E24329_01/web.1211/e24485/…
Арджан Тиймс
2
На данный момент я полагаю, что вы всегда должны убедиться, что ваш JACC-провайдер связан с JASPIC-провайдером, поэтому вы также обязаны писать. Я еще не прошел этот маршрут, но он у меня на столе, чтобы попробовать.
Лейрд Нельсон
@LairdNelson, если у вас есть время, вы, вероятно, должны написать ответ вокруг своего комментария JASPIC. Это звучит многообещающе, и в этом вопросе есть награда в 300 репутаций.
Jimhark
5
Здравствуй; не пытаясь держать кого-то в напряжении. :-) У меня нет ответа, который я мог бы спешить. Я просто вспоминаю, как Рон Монзилло советовал мне, что единственный способ получить назначения принципала-роли «в» провайдера JACC таким способом, который он может понять, - это эффективно связать реализацию JASPIC с ним.
Лейрд Нельсон

Ответы:

3

Краткий ответ: нет стандартного способа сделать это.

Хотя Glassfish и JBoss поддерживают сопоставления между субъектами и ролями, JACC не предполагает, что это делают все контейнеры, и поэтому делегирует ответственность за сохранение этих сопоставлений реализации поставщика JACC. Из документов (см .: PolicyConfiguration.addToRoleметод ):

Задача поставщика политик - обеспечить, чтобы все разрешения, добавленные к роли, предоставлялись принципалам, «сопоставленным с ролью».

Другими словами, вам нужно реализовать это внутри провайдера JACC для каждого контейнера. Например, для JBoss вы можете использовать один из подклассов AbstractRolesMappingProvider.

Диего
источник
Кроме того, переносимый поставщик может игнорировать сопоставление ролей контейнера; например, можно предположить, что любой принципал подразумевает роль приложения с тем же именем, если приложение каким-либо образом (например, через PolicyContextHandlerспециально зарегистрированного провайдером для этой цели) не передает иное. Другой поставщик мог бы также полностью игнорировать понятие ролей (и, следовательно, предоставленных контейнером PolicyConfiguration), вместо этого работая исключительно на (предоставленных приложением) сопоставлениях основных и разрешений (и где эти разрешения не должны быть ограничены теми JACC).
Uux
Примечание 2: Начиная с Java EE 8, сопоставление группы ролям 1: 1 стало новым значением по умолчанию (что, однако, только приводит нас к середине, поскольку роли все равно должны быть статически объявлены заранее - при условии, что пользовательский поставщик JACC не в результате).
Uux