Hi Tos...
I'm just now getting back into looking into this problem. Thank you for
posting some clues that helped me get it working.
#add cn. cn is returned by LDAP that I want to search db with, add it the
to the list of attributeList
cas.authn.ldap[1].principalAttributeList:
Aaron,
Do you also have an attribute list for the authn definition? like:
cas.authn.ldap[0].principalAttributeList=cn,sn,...
If so, your attributes may be coming from attribute list instead of
attribute-repository. Check you repository settings (and maybe comment out
attribute list).
Cas can
Yes, the attribute repository is cas.authn.attribute-repository.jdbc[0]
It works fine with my cas.authn.ldap[0] and cas.authn.jdbc.search[0]
authentication services, but seems to get skipped when I use the
cas.authn.pac4j.oidc[0].azure authentication service. The attributes I get
back are the
Thank you for looking. Yes, the attributes are defined under
cas.authn.attribute-repository.jdbc[0]... and as long as I use one of the
two non-delegated authentication methods (jdbc or ldap) the properties come
through fine. If I use the Azure AD authentication method, though, the only
Hi
We have recently upgraded to CAS 6.6.10 and occasionally noticing
'org.hibernate.TransactionException: Unable to commit against JDBC
Connection' during REST API JWT creation (URL: /v1/tickets/tgtId:xxx).
On checking the code, seems like this is recent change
in
Aaron,
Do you have the attribute repository defined with:
cas.authn.attribute-repository. ... properties?
Ray
On Wed, 2023-08-30 at 13:04 -0700, Aaron Chantrill wrote:
Notice: This message was sent from outside the University of Victoria email
system. Please be cautious with links and
Hi, Thanks for this answer, I was indeed able to fix this part of the problem
with it. Regards
Le 25-Aug-2023 20:56:21 +0200, jbanner6...@gmail.com a crit:
Looks like from your config, you don't have a static value set for gauth
encryption, each restart without consistent values would
Hi, Thank you very much for this very valuable answer ! I totally forgot to
make those keys persistent, after seeing them during the startups and not even
being able to notice they were different each time ... And I also purposely
ignored 'publishToMavenLocal' in my command line, as I
Hi,
AFAIK you are only vulnerable if you use "inline groovy" scripts
(as can be seen in
https://apereo.github.io/cas/6.6.x/integration/Attribute-Release-Policy-InlineGroovy.html
)
So AFAIK groovy scripts in their own xxx.groovy file are not vulnerable
(non vulnerable examples:
