Feature lost when switching from CAS 3 to CAS 5/6

31 views
Skip to first unread message

Fabrice Bacchella

unread,
Aug 27, 2019, 12:14:20 PM8/27/19
to CAS Community
I have too separated AD, with different login that maps to the same users

in AD1, I have entry like:

dn: ....
  sAMAccountName: login1
  memberOf: group1

In AD2, I have:
dn: ....
  sAMAccountName: login2
  employeeID: login1

both login1 and login2 maps to the same user. I was using CAS SSO with kerberos ticket in the format login2@AD2 was indeed identified as login1@AD1, and the 
good attributes memberOf were returned, as it was possible to have good control of attribute resolution, the separation of credentialsToPrincipalResolvers and attribute resolution was better.

I can play with AD2 (I was able to add employeeID, but AD1 access is much more restricted for me).

Since switching to version 5 (and I tried 6.0 too), I lost that, because principal mapping and attribute resolution is done in the same phase, during authentication, and before principal mapping. So memberOf is searched in AD1, but using the principal resolved as login2@AD2 and of course fails. The search filter is defined as

searchFilter: "sAMAccountName={user}"

but the value user is not accessible during the authentication phase and defined with the value login2.


But this page says absolutely nothing useless, it just talk about separation of AuthenticationHandler and PrincipalResolver, but there is absolutely no useful informations that says how to do that.

This blog entry https://apereo.github.io/2019/03/15/cas61x-attribute-repositories/ talks about something similar, but it's done at service level, and I want it to be done at server level. And it's for 6.1, that is not released yet.

Am I stuck with CAS 3 ? 
Reply all
Reply to author
Forward
0 new messages