CAS 6.6.8 JDBC属性仓库未用Principal查询：Bug还是配置错误？

问题根源 #

当用户通过邮箱登录时，LDAP认证成功后会返回uid（用户名）作为CAS的Principal，但你的JDBC属性仓库默认使用**登录时输入的Credential（即邮箱）**执行查询，而数据库中用户属性是以用户名存储的，自然查不到结果。用户名登录正常是因为此时Credential和Principal的uid值一致，查询能匹配到数据。

修复配置 #

需要修改JDBC属性仓库的配置，强制其使用Principal的ID（也就是LDAP返回的uid）执行查询，而非登录输入的Credential：

1. 开启使用PrincipalId的配置：

cas.authn.attribute-repository.jdbc[0].usePrincipalId=true

2. 确保SQL语句的占位符对应数据库的用户名字段（USER_ID），可调整为更明确的形式：

cas.authn.attribute-repository.jdbc[0].sql=select a, b, c from user_table where USER_ID = ?

若保留原{0}占位符，只要开启usePrincipalId=true，CAS就会用Principal的uid替换占位符，匹配数据库的USER_ID字段。

验证逻辑 #

开启usePrincipalId=true后，无论用户用用户名还是邮箱登录，JDBC属性仓库都会使用LDAP返回的uid（用户名）作为查询条件，与数据库中存储的USER_ID匹配，即可正常获取属性。

内容的提问来源于stack exchange，提问作者Micho Rizo