我使用以下 docker 镜像设置了 jBPM：jboss/jbpm-server-full:latest
按照https://blog.kie.org/2021/02/migration-jbpm-images-secured-by-ldap-to-elytron.html中提到的步骤操作后（包括修改 kie-server.war文件与两个 LDAP 用户属性文件）。
到目前为止，我终于获得了身份验证，我用新的 KieLdap 替换了旧的 OTHER 身份验证机制，当我使用正确的 LDAP 用户名（即“ldapuser”）以及正确的密码登录时，我会看到不同的错误当我使用不存在的用户或错误的密码登录时查看：
登录失败：未授权
以其他用户身份登录
这对我来说意味着：登录理论上是有效的！
在 LDAP 服务器（FreeIPA）上，我看到 jBPM 请求绑定到用户以及获取用户所属的所有组。
执行用户身份验证：
[15/Jan/2024:10:41:01.226351348 +0100] conn=19193 op=0 BIND dn="uid=tech_jbpm,cn=users,cn=accounts,dc=example,dc=ch" method=128 version=3
[15/Jan/2024:10:41:01.229601791 +0100] conn=19193 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000385959 optime=0.003256677 etime=0.003636806 dn="uid=tech_jbpm,cn=users,cn=accounts,dc=example,dc=ch"
[15/Jan/2024:10:41:01.230835297 +0100] conn=19193 op=1 SRCH base="cn=users,cn=accounts,dc=example,dc=ch" scope=1 filter="(uid=ldapuser)" attrs="1.1"
[15/Jan/2024:10:41:01.231469269 +0100] conn=19193 op=1 RESULT err=0 tag=101 nentries=1 wtime=0.000181602 optime=0.000634202 etime=0.000810154
[15/Jan/2024:10:41:01.232423161 +0100] conn=19193 op=2 UNBIND
获取用户所在组：
[15/Jan/2024:10:41:01.235885094 +0100] conn=19194 op=0 BIND dn="uid=tech_jbpm,cn=users,cn=accounts,dc=example,dc=ch" method=128 version=3
[15/Jan/2024:10:41:01.239461648 +0100] conn=19194 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000513500 optime=0.003582121 etime=0.004090225 dn="uid=tech_jbpm,cn=users,cn=accounts,dc=example,dc=ch"
[15/Jan/2024:10:41:01.240776989 +0100] conn=19194 op=1 SRCH base="cn=users,cn=accounts,dc=example,dc=ch" scope=1 filter="(uid=ldapuser)" attrs="1.1"
[15/Jan/2024:10:41:01.242193465 +0100] conn=19194 op=1 RESULT err=0 tag=101 nentries=1 wtime=0.000520836 optime=0.001418289 etime=0.001932418
[15/Jan/2024:10:41:01.242759072 +0100] conn=19194 op=2 SRCH base="cn=groups,cn=accounts,dc=example,dc=ch" scope=2 filter="(member=uid=ldapuser,cn=users,cn=accounts,dc=example,dc=ch)" attrs=" cn"
[15/Jan/2024:10:41:01.253362800 +0100] conn=19194 op=2 RESULT err=0 tag=101 nentries=26 wtime=0.000225495 optime=0.010595889 etime=0.010815564
[15/Jan/2024:10:41:01.256216795 +0100] conn=19194 op=3 UNBIND
我尝试通过将以下记录器添加到standalone.xml 文件来启用Elytron Security 模块的调试：
<logger category="org.wildfly.security">
<level name="DEBUG"/>
<handlers>
<handler name="CONSOLE"/>
</handlers>
</logger>
但是在验证用户身份时不会生成任何输出。
存在一些错误，这些错误在配置 LDAP 之前并不存在：
jbpm | 10:08:35,421 INFO [org.kie.server.controller.websocket.client.WebSocketKieServerControllerImpl] (KieServer-ControllerConnect) Kie Server points to non Web Socket controller 'http://localhost:8080/business-central/rest/controller', using default REST mechanism
jbpm | 10:08:35,666 WARN [org.kie.server.services.impl.controller.DefaultRestControllerImpl] (KieServer-ControllerConnect) Exception encountered while syncing with controller at http://localhost:8080/business-central/rest/controller/server/sample-server error Error while sending PUT request to http://localhost:8080/business-central/rest/controller/server/sample-server response code 405
如何在没有任何身份验证工作日志输出的情况下进一步调试此问题？
所有执行的 LDAP 设置步骤记录如下：
# Blogs: https://blog.kie.org/2021/02/migrating-jbpm-images-secured-by-ldap-to-elytron.html, https://www.mastertheboss.com/jbossas/jboss-security/configuring-ldap-based-authentication-with-elytron-on-wildfly/
FULL MIGRATION
In the case of kie-server-showcase image, only the kie-server.war is present (no KieLoginModule dependencies) and therefore, it’s possible to make a full migration to Elytron.
Elytron is based on a security-domain concept, in other words, on the representation of a security policy. It is backed by security-realm/s, and resources to make transformations (role-decoder, permission-mapper and others).
In this practical example, we are going to use Elytron LDAP Security Realm to access LDAP backend and verify credentials as well as obtain attributes associated with an identity.
More complex scenarios would allow having several security realms, and by means of a security-mapper, determine which attributes would be retrieved from each security realm.
0. Modify the kie-server.war file.
docker cp jbpm:/opt/jboss/wildfly/standalone/deployments/kie-server.war ./
Unpack the war on an ubuntu machine.
scp [email protected]:/opt/jbpm/kie-server.war ./
Then add these two files:
nano kie-server/WEB-INF/classes/jbpm.user.info.properties
ldap.user.ctx=cn\=users,cn\=accounts,dc\=example,dc\=ch
ldap.role.ctx=cn\=groups,cn\=accounts,dc\=example,dc\=ch
ldap.user.filter=(uid\={0})
ldap.role.filter=(cn\={0})
nano kie-server/WEB-INF/classes/jbpm.usergroup.callback.properties
ldap.user.ctx=cn\=users,cn\=accounts,dc\=example,dc\=ch
ldap.role.ctx=cn\=groups,cn\=accounts,dc\=example,dc\=ch
ldap.user.roles.ctx=cn\=groups,cn\=accounts,dc\=example,dc\=ch
ldap.user.filter=(uid\={0})
ldap.role.filter=(cn\={0})
ldap.user.roles.filter=(member\={0})
ldap.bind.user=uid\=tech_jbpm,cn\=users,cn\=accounts,dc\=example,dc\=ch
ldap.bind.pwd=9sdvYxGksGRX7stug7
java.naming.provider.url=ldap://10.1.20.10:389
Repack the kie-server.war and upload & mount it on the server:
jar -cvf kie-server.war *
scp ./kie-server.war [email protected]:/opt/jbpm/kie-server.war
1.- First, let’s remove the security-domain called other at legacy security subsystem, as it will be no longer used:
[root@c01-lxc-jbpm-001 jbpm]# docker exec -it jbpm bash
[jboss@5a3ffa8318d2 bin]$ bash jboss-cli.sh
[standalone@localhost:9990 /] connect
[standalone@localhost:9990 /] /subsystem=undertow/application-security-domain=other:remove
[standalone@localhost:9990 /] /subsystem=ejb3/application-security-domain=other:remove
Then reload Kie Server:
[standalone@localhost:9990 /] reload
And connect again:
[standalone@localhost:9990 /] connect
3.- Define the directory context to connect with LDAP and the LDAP Realm into Elytron:
[standalone@localhost:9990 /] /subsystem=elytron/dir-context=ldap-connection:add(url=ldap://10.10.0.10:389, principal="uid=tech_jbpm,cn=users,cn=accounts,dc=example,dc=ch", credential-reference={clear-text="secret"})
[standalone@localhost:9990 /] /subsystem=elytron/ldap-realm="KieLdap":add(dir-context=ldap-connection, \
direct-verification=true, \
identity-mapping={search-base-dn="cn=users,cn=accounts,dc=example,dc=ch", \
rdn-identifier="uid", \
attribute-mapping=[{filter-base-dn="cn=groups,cn=accounts,dc=example,dc=ch",filter="(member=uid={0},cn=users,cn=accounts,dc=example,dc=ch)",from="cn",to="Roles"}]})
Notice that the LDAP connection needs the principal (bindDN) and its password as the used LDAP server doesn’t allow anonymous binding.
Retrieved roles are mapped from “cn” to “Roles”, where the RoleDecoder will take them.
This RoleDecoder component (as its name indicates) is in charge of decoding user’s roles.
Our simple-role-decoder (from-roles-attribute) is pretty straightforward: roles are obtained directly from the attribute “Roles”.
<simple-role-decoder name="from-roles-attribute" attribute="Roles"/>
4.- Create the security domain in Elytron, named KIEDomain, (any name is valid, as we will map it later to the one defined at application level) and add it the previous LDAP realm, and the default-permission-mapper:
[standalone@localhost:9990 /] /subsystem=elytron/security-domain=KIEDomain:add(realms=[{realm=KieLdap,role-decoder=from-roles-attribute}], default-realm="KieLdap", permission-mapper=default-permission-mapper)
5.- Next, we need to define the HTTP authentication factory: for kie-server, it’s needed to link the mechanisms for BASIC and FORM authentications:
[standalone@localhost:9990 /] /subsystem=elytron/http-authentication-factory=ldap-http-auth:add(http-server-mechanism-factory=global,security-domain=KIEDomain,mechanism-configurations=[{mechanism-name=BASIC,mechanism-realm-configurations=[{realm-name=KieLdap}]}, {mechanism-name=FORM}])
6.- Map the application security domain (other, as it is the one specified at jboss-web.xml) to our Elytron security domain (KIEDomain) for the undertow and ejb3 subsystems:
[standalone@localhost:9990 /] /subsystem=undertow/application-security-domain=other:add(security-domain=KIEDomain)
[standalone@localhost:9990 /] /subsystem=ejb3/application-security-domain=other:add(security-domain=KIEDomain)
7.- Update the messaging-activemq (JMS) to point to our Elytron security domain (KIEDomain) and undefine (remove) the default security domain given by WildFly:
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default:write-attribute(name=elytron-domain, value=KIEDomain)
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default:undefine-attribute(name=security-domain)
8.- Disable JACC from legacy security subsystem and enable it at elytron by adding the default policy:
Does not work: [standalone@localhost:9990 /] /subsystem=security:write-attribute(name=initialize-jacc, value=false)
[standalone@localhost:9990 /] /subsystem=elytron/policy=jacc:add(jacc-policy={})
[standalone@localhost:9990 /] reload
[standalone@localhost:9990 /] connect
要启用 elytron 跟踪，请尝试从 Wildfly 控制台执行
/subsystem=logging/logger=org.wildfly.security/:add(level=TRACE,use-parent-handlers=true) /subsystem=logging/logger=org.wildfly.elytron/:add(level=TRACE,use-parent-handlers=true) /subsystem=logging/logger=org.wildfly.extension.undertow/:add(level=TRACE,use-parent-handlers=true)
或将它们添加到您的独立配置文件中。
您还可以查看此配置（该存储库的 ldap_last 分支）