Liferay имеет чрезвычайно расширяемую архитектуру. Вы сами решаете, что хотите переопределить в Liferay — у него где-то есть расширение. В этой записи блога показано, как делегировать функции аутентификации и авторизации Liferay на WSO2 Identity Server.
Одной из сложных частей, которые мы нашли в этой интеграции, является импорт пользователей / групп LDAP. Вы можете подключить LDAP к Liferay, но для аутентификации пользователей в Liferay по базовому LDAP необходимо импортировать всех пользователей и группы в базовую базу данных Liferay, которая по умолчанию работает на Hypersonic.
Поскольку нам нужно только хранить пользовательские данные в одном LDAP, мы хотели избежать этого дублирования. Но это было не так просто, как мы думали. Если вам нужно этого избежать, то нам нужно написать полный слой постоянства. Чтобы лучше это понять, мне нужно уточнить. Давайте сделаем шаг назад и посмотрим, как работают аутентификация и авторизация в Liferay.
У Liferay есть цепочка аутентификаторов. Когда вы вводите свое имя пользователя / пароль, вызывается цепочка аутентификаторов. Это место, где мы подключили WSO2ISAuthenticator.
auth.pipeline.pre=org.wso2.liferay.is.authenticator.WSO2ISAuthenticator auth.pipeline.enable.liferay.check=false wso2is.auth.service.endpoint.primary=https://localhost:9443/services/
Приведенная выше конфигурация [которая должна быть в liferay_home / tomcat / webapps / ROOT / WEB-INF / classes / portal-ext.properties] говорит Liferay загрузить наш собственный аутентификатор. Кроме того, вторая запись говорит, что, как только наш аутентификатор загружен, не вызывайте rest в цепочке. В противном случае также будет вызываться аутентификатор Liferay по умолчанию. Третья запись указывает на службу AuthenticationAdmin, работающую на WSO2 Identity Server.
Теперь имя пользователя / пароль входит в WSO2ISAuthenticator, и он обращается к WSO2 Identity Server через SOAP для аутентификации пользователя. Когда аутентификация завершена, управление снова передается в контейнер Liferay.
Теперь самая сложная часть. Liferay имеет свою собственную модель разрешений: кто должен видеть портлеты, кто должен добавлять портлеты и т. Д. Для этого ему необходимо определить, какие роли Liferay присоединены к зарегистрированному пользователю или какие роли Liferay присоединены к какой-либо группе. зарегистрированный пользователь принадлежит. Чтобы получить эти подробности, он должен поговорить с базовым уровнем персистентности, который будет загружать детали из базовой базы данных Liferay. Вот почему мы хотели, чтобы пользователи импортировались сюда из LDAP.
Несмотря на то, что это возможно, мы решили не писать слой постоянства. Мы только хотели отменить аутентификацию и авторизацию.
Даже в случае авторизации — есть два типа. Модель авторизации, управляемая Liferay для отображения / добавления портлетов на портале, и модель авторизации, используемая в самом портлете для отображения контента в портлете.
Первый тип выполняется путем назначения разрешений на управление портлетами для данной роли Liferay и назначения членов [групп / пользователей] для этой роли из базового LDAP. Мы не хотели этого делать, потому что это очень сильно относится к администрации портала и относится к Liferay. Но вторая модель — это та, которая напрямую связана с бизнес-функциями. Это то, что мы хотели сделать в мелкозернистой манере.
Давайте углубимся в это …
Даже вторая модель может быть сделана с ролями и разрешениями Liferay. Всякий раз, когда вы хотите визуализировать что-то в портлете, требующее некоторой ограниченной аудитории, перед рендерингом вам нужно вызвать
req.isUserInRole («roleNme») . Это также соответствует JSR, но есть и недостатки.
1. Наши бизнес-функции в развертывании SOA не должны регулироваться ролями Liferay. Liferay может быть только одним каналом для доступа к бизнес-функциям.
2. С этой моделью мы можем добиться только контроля доступа на основе ролей.
Liferay, также имеет свой собственный способ проверки разрешений в портлете через PermissionChecker API. Вы можете взглянуть на
это для получения дополнительной информации.
Наш подход заключался в написании служебной функции
hasPermission () . Если вы расширили свой портлет из
org.wso2.liferay.xacml.connector.SecuredGenericPortlet, тогда он будет автоматически доступен для вас. Или же вы можете напрямую вызвать его через
AuthzChecker.hasPermission ().
Эти функции доступны из файла org.wso2.liferay.xacml.connector.jar .
Вы можете скопировать все зависимости jar
отсюда и скопировать их в liferay_home / tomcat / lib / ext.
Соединение между разъемом XACML, развернутым в Liferay, и механизмом WAC2 XACML осуществляется через Thrift. Вам необходимо добавить следующие свойства в файл portal-ext.properties.
wso2is.auth.thrift.endpoint=localhost wso2is.auth.thrift.port=10500 wso2is.auth.thrift.connection.timeout=10000 wso2is.auth.thrift.admin.user=admin wso2is.auth.thrift.admin.user.password=admin wso2is.auth.thrift.endpoint.login=https://localhost:9443/
Поскольку по умолчанию Identity Server использует самозаверяющий сертификат, либо вы импортируете его открытый сертификат в хранилище доверенных сертификатов Liferay, либо задаете два следующих свойства в файле portal-ext.properties, указывающих на хранилище ключей Identity Server.
wso2is.auth.thrift.system.trusstore=/wso2is-3.2.3/repository/resources/security/wso2carbon.jks wso2is.auth.thrift.system.trusstore.password=wso2carbon
Обратите внимание, что вышеуказанная конфигурация протестирована с Liferay 6.1.1 и WSO2 Identity 3.2.3 / 4.0.0.