>> 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 A quinta-feira, 12 de outubro de 2023 à(s) 03:42:27 UTC+1, Ray Bon escreveu: > 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. > > > 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 > > -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/4ee7be58-2990-4e51-a127-2a3c6743c295n%40apereo.org.
