CAS 66x, how to make association between authentication handlers and attribute repositories / PersonAttributeDaos

[Luís Costa]

Hello,


I'm implementing CAS 6.6.x (currently I have 6.6.8), and I need to make an association between authentication handlers and attribute repositories / PersonAttributeDaos, for example, LdapAuthHandler[0] => Dao1, Dao2 and JdbcAuthHandler[0] => Dao1, Dao3.

The goal is that each auth handler only tries to get attributes from the attribute repositories that make sense to it.


I'm trying to do this, by creating a custom property in cas.properties for each auth handler, that holds a comma-separated list of one or more attribute repositories Ids (defined in standard props  "cas.authn.attribute-repository.<ldap/jdbc/etc>.id").
I got this ideia from the standard property "cas.person-directory.active-attribute-repository-ids".

Then, my plan is to extend the PersonDirectoryPrincipalResolver and manipulate the context.attributeRepository.personAttributeDaos, so that only the Daos that the auth handler "supports" are "executed".


Does this makes sense? Is it a possible and logic solution? Is there a better "standard solution" ?


Best regards,

Luís Costa

[Ray Bon]

Luís,

It is possible to get attributes at time of authentication for ldap and jdbc.

cas.authn.ldap[0].principal-attribute-list= \

mail, \

cn, \

sn, \

givenName

That will give you one source. See https://apereo.github.io/cas/6.6.x/authentication/LDAP-Authentication.html

Does your user identifier exist in the non target DAOs?

If not, then that DAO will not return any attributes, so the only cost is time taken to perform the lookup.

There is a custom attribute resolver option, https://apereo.github.io/cas/6.6.x/integration/Attribute-Resolution-Custom.html

And scriptable filter option, https://apereo.github.io/cas/6.6.x/integration/Attribute-Resolution-LDAP.html#ldap-scriptable-search-filter 

The applicationContext will have some properties that identify the authn method.

The above two approaches will get user attributes prior to person directory actions.

I have not worked with person directory so can not say how to manipulate it.

Ray

 

On Wed, 2023-10-11 at 06:48 -0700, Luís Costa wrote:

Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

[Luís Costa]

>> Luís,

Hello Ray,

Thank you for your quick and informative reply!

>> It is possible to get attributes at time of authentication for ldap and jdbc.
>>
>> cas.authn.ldap[0].principal-attribute-list= \
>> mail, \
>> cn, \
>> sn, \
>> givenName
>>
>> That will give you one source.
>> See https://apereo.github.io/cas/6.6.x/authentication/LDAP-Authentication.html

I've read that somewhere since CAS 4.1.x, what you say is possible.

I understand that option has better performance, using only one (eg LDAP) connection instead of two (eg LDAP) connections.


The official docs mention that:

6.6.X / Integration / Attribute Resolution
https://apereo.github.io/cas/6.6.x/integration/Attribute-Resolution.html#person-directory

Note that in most if not all cases, CAS authentication is able to retrieve and resolve attributes from the authentication source,
which would eliminate the need for configuring a separate resolver specially if both the authentication and the attribute source are the same.
Using separate resolvers should only be required when sources are different,
or when there is a need to tackle more advanced attribute resolution use cases such as cascading, merging, etc.
See this guide for more info.


My scenario is more complicated,
we have multiple authentication handlers
and each of them potencially has more than one specific/different repository/IPersonAttributeDao sources,
and the attributes I can obtain directly from the authentication handler are not enough,
they need to be manipulated and/or cascaded from one repository/dao to another,
so I believe that I fall in the
"Using separate resolvers should only be required when sources are different, or when there is a need to tackle more advanced attribute resolution use cases such as cascading, merging, etc."
scenario mentioned above,
which means I will have to use (a custom) PersonDirectory Personal Resolver to deal with my scenario.


Has a footnote, on a semantic area, I have some doubts about the "repository" and "IPersonAttributeDao" concepts.
On one hand, it seems to be, while debugging, that a PersonDirectoryPrincipalResolver has ONE repositorý which can contain ONE OR MORE IPersonAttributeDao implemetations,
on the other hand, on cas.properties, a "cas.authn.attribute-repository.ldap/jdbc/...[0/1]..." configuration is transformed into a IPersonAttributeDao implementation,
so I'm not sure if, at a conceptual level, a repository contains DAOs or if a repository is a DAO.

>> Does your user identifier exist in the non target DAOs?
>> If not, then that DAO will not return any attributes, so the only cost is time taken to perform the lookup.

The user identifier might exist in more than one of the DAOs, so I expect that in some cases, attributes are returned from different DAOs for the same user.

>> There is a custom attribute resolver option,
>> https://apereo.github.io/cas/6.6.x/integration/Attribute-Resolution-Custom.html

Thank's for pointing that link,
I think I will use it for yet another situation different from the above,
a repository/DAO not ldap/jdbc.

>> And scriptable filter option,
>> https://apereo.github.io/cas/6.6.x/integration/Attribute-Resolution-LDAP.html#ldap-scriptable-search-filter

I think I will not use this.

My LDAP attributes are being returned correctly, I just need to manipulate them as cascade them no another repository/DAO.

>> The applicationContext will have some properties that identify the authn method.

I not sure if you'te talking about the PersonDirectory PrincipalResolver context, but in my solution I will be using it.

>> The above two approaches will get user attributes prior to person directory actions.

That would be the most performant option, but it's not enough for my scenario.

>> I have not worked with person directory so can not say how to manipulate it.

I'm convinced that I would have to use person directory, to the point of doing some code customization.

I'm currently studying how to extend the person directory current behaviour to suit my needs, using information in,
https://apereo.github.io/cas/6.6.x/installation/Configuring-Principal-Resolution.html#custom
https://apereo.github.io/cas/6.6.x/configuration/Configuration-Management-Extensions.html
https://fawnoos.com/2019/03/15/cas61x-attribute-repositories/
https://fawnoos.com/2020/10/21/cas62-authn-handlers/
https://fawnoos.com/2021/10/28/cas65-attribute-resolution-lifecycle-states/#inactive-attribute-repositories
https://fawnoos.com/2023/08/12/cas70-attribute-repositories/
(not sure if this CAS 7x last link applies to CAS 66x)



>> Ray

Thanks again for your reply!


Kind Regards,

Luis