So I've continue to try to get this to work, and implemented mod_auth_cas with SAML support in apache server so as to maybe see if that triggered the attribute merging, specifically using the cas-attribute directive to I was hoping force pulling/releasing of attributes. Using Require valid-user all works and I see SAML messaging so fundamentally I know that test instrumentation works.

Elevating the logging on the AttributeRelease functions doesn't give any real hints, other than stuff like...

attributeReleasePolicy=ReturnAllAttributeReleasePolicy(super=AbstractRegisteredServiceAttributeReleasePolicy(attributeFilter=null,
 principalAttributesRepository=DefaultPrincipalAttributesRepository(), 
consentPolicy=DefaultRegisteredServiceConsentPolicy(enabled=true,
 excludedAttributes=null, includeOnlyAttributes=null), 
authorizedToReleaseCredentialPassword=false, 
authorizedToReleaseProxyGrantingTicket=false,
 excludeDefaultAttributes=false, 
authorizedToReleaseAuthenticationAttributes=false, principalIdAttribute=null)),



Totally unfounded but I'm wondering based upon the above if the problem is that the Repository= DefaultPrincipleAttributesRepository shouldn't end up
being something like personDirectoryAttributeRepository or something????

I've got the following as policy for this service and it's my only service definition so I know it's being invoked.


attributeReleasePolicy:

  {

    @class: org.apereo.cas.services.ReturnAllAttributeReleasePolicy

    principalAttributesRepository:

    {

      @class: 
org.apereo.cas.authentication.principal.DefaultPrincipalAttributesRepository

      expiration: 0

    }

    consentPolicy:

    {

      @class: 
org.apereo.cas.services.consent.DefaultRegisteredServiceConsentPolicy

      enabled: true

    }

    authorizedToReleaseCredentialPassword: false

    authorizedToReleaseProxyGrantingTicket: false

    excludeDefaultAttributes: false

    authorizedToReleaseAuthenticationAttributes: false

  }




I see that the personDirectory is getting invoked against my LDAP...

[36m2019-11-01 12:56:38,712 DEBUG [org.apereo.cas.util.LdapUtils] - <Creating 
LDAP bind connection initializer via [cn

=Directory Manager]>^[[m

^[[36m2019-11-01 12:56:38,744 DEBUG [org.apereo.cas.util.LdapUtils] - <Creating 
LDAP connection pool configuration for [

ldap://100.10.1.230:3131]>^[[m

^[[36m2019-11-01 12:56:38,811 DEBUG [org.apereo.cas.util.LdapUtils] - <Created 
[BIND] passivator for [ldap://100.10.1.23

0:3131]>^[[m

^[[36m2019-11-01 12:56:38,811 DEBUG [org.apereo.cas.util.LdapUtils] - 
<Initializing ldap connection pool for [ldap://100

.10.1.230:3131] and bindDn [cn=xxxxxxxxxx]>^[[m

^[[36m2019-11-01 12:56:38,902 DEBUG 
[org.apereo.cas.config.CasPersonDirectoryConfiguration] - <LDAP attributes are 
fetch

ed from [ldap://100.10.1.230:3131] via filter [uid={0}]>^[[m

^[[36m2019-11-01 12:56:38,903 DEBUG 
[org.apereo.cas.config.CasPersonDirectoryConfiguration] - <Configured result 
attribu

te mapping for [ldap://100.10.1.230:3131] to be [{uid=uid, 
inetUserStatus=inetUserStatus, dn=dn, memberOf=memberOf, cn=c

ommonName}]>^[[m

^[[36m2019-11-01 12:56:38,905 DEBUG 
[org.apereo.cas.config.CasPersonDirectoryConfiguration] - <Configured subtree 
search

ing for [ldap://100.10.1.230:3131]>^[[m

^[[36m2019-11-01 12:56:38,906 DEBUG 
[org.apereo.cas.config.CasPersonDirectoryConfiguration] - <Initializing LDAP 
attribu

te source for [ldap://100.10.1.230:3131]>^[[m

^[[36m2019-11-01 12:56:39,020 DEBUG 
[org.apereo.cas.config.CasPersonDirectoryConfiguration] - <Configured attribute 
repo

sitory sources to merge together: 
[[org.apereo.services.persondir.support.ldap.LdaptivePersonAttributeDao@1b293404]]>^[[

m

..but end of the day the only attributes I'm seeing getting released are the basic Framed User etc. attribute from the RADIUS authentication response.

Stumped....

On 2019-11-01 1:09 p.m., Ray Bon wrote:
Colin,

It has been a long time since I used the default page so I do not know its behaviour. You can back up the logger to org.apereo.cas.services to get many more messages related to the service. That along with
<AsyncLogger name="org.ldaptive" level="debug" includeLocation="true" />
might provide more details in case there are ldap connection issues.

If you can look at logs from RADIUS and LDAP, they may tell you if the problem is on that end.

Ray

On Fri, 2019-11-01 at 10:59 -0400, Colin Ryan wrote:
Ray,

I had already set the attribute release directive in the basic HTTPIMAP all access service definition.

You've helped my brain tweak on the concept that only principal attributes are automatically released while all others must be explicitly added to defaults or service definitions. But your example below is for LDAP auth. I'm trying to use RADIUS auth - which is releasing Framed Protocol and Service Type - and using LDAP to fill out the attribute set, via cas.authn.attribute-repository.ldap[].....

I set the debug to what you suggested and Logged in to the CAS default Login page and just see the RADIUS attribute, and no reference in the logs to AbstractRegisteredServiceAttributeReleasePolicy.

Is the "Click here to view attributes resolved and retrieved for " expected to show all the native and resolved attributes, I want to make sure I'm using the right test instrument.

My service definition is:

  {
          "@class" : "org.apereo.cas.services.RegexRegisteredService",
          "serviceId" : "^(https|imaps)://.*",
          "name" : "HTTPS and IMAPS",
          "id" : 10000001,
         "attributeReleasePolicy" : {
             "@class" : 
"org.apereo.cas.services.ReturnAllAttributeReleasePolicy"
           }
}

Sorry for my naivete..

Colin



On 2019-10-29 12:40 p.m., Ray Bon wrote:
You can set attributes to be released by default (normally no attributes are released),

cas.authn.ldap[1].principalAttributeList=mail, \
                                          cn, \
                                          sn


--
Ray Bon
Programmer Analyst
Development Services, University Systems
2507218831 | CLE 019 | r...@uvic.ca <mailto:r...@uvic.ca>

I respectfully acknowledge that my place of work is located within the ancestral, traditional and unceded territory of the Songhees, Esquimalt and WSÁNEĆ Nations.
--
- 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 <mailto:cas-user+unsubscr...@apereo.org>. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/d736dbdb27e413c258ba914b2c2fb34b02e4323e.camel%40uvic.ca <https://groups.google.com/a/apereo.org/d/msgid/cas-user/d736dbdb27e413c258ba914b2c2fb34b02e4323e.camel%40uvic.ca?utm_medium=email&utm_source=footer>.


--
- 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/8a73f58c-32bc-4445-d523-7fd8890a57c3%40caveo.ca.

Reply via email to