Attribute Resolution and Merging Radius and LDAP

[Colin Ryan]

Folks,

I'm trying to have Radius be my Authentication Method but gather attributes from the LDAP entry for the user. The LDAP database is the same one that is actually backing the RADIUS auth.

Seemed straight forward enough based upon: https://apereo.github.io/2018/10/18/cas5-radius-mfa-authn/

The authentication part is working and I can see in the Logs that the personDirectory function is getting the attributes, but they aren't been show as the available attributes in the default no-resource user page that CAS uses in it's most primitive state.

The authentication seems to put the basic RADIUS response into the SimplePrincipal

[SimplePrincipal(id=colinr, attributes={Service-Type=Framed-User, Framed-Protocol=PPP})]>

And the LDAP Attribute Resolver seems to be working

DEBUG [org.apereo.services.persondir.support.ldap.LdaptivePersonAttributeDao] - <Converted
 ldap DN entry [uid=colinr, ou=People, o=caveo, o=isp] to attribute map {uid=[colinr], inetUserStatus=[Active], cn=[9999
999]}>^[[m
^[[36m2019-10-27 13:31:06,336 DEBUG [org.apereo.services.persondir.support.MergingPersonAttributeDaoImpl] - <Retrieved a
ttributes='[NamedPersonImpl[name=colinr,attributes={uid=[colinr], inetUserStatus=[Active], commonName=[9999999]}]]' for
query='{username=[colinr]}', isFirstQuery=false, currentlyConsidering='org.apereo.services.persondir.support.ldap.Ldapti
vePersonAttributeDao@1e224cb6', resultAttributes='null'>^[[m

But the two set's never merge.

I'm sure it's just newbie mistake but I've read the documentation a number of time, and can't seem to figure it out.

Config is below CAS 6.0.5.1

cas.authn.accept.users=

#cas.authn.ldap[0].order=1

## Radius

cas.authn.radius.name=CAS1

cas.authn.radius.server.protocol=PAP

cas.authn.radius.server.retries=1

cas.authn.radius.client.authenticationPort=1645

cas.authn.radius.client.sharedSecret=xxxx

cas.authn.radius.client.inetAddress=100.10.1.182

cas.authn.radius.client.accountingPort=1646

# LDAP As Attribute Repository

cas.authn.attribute-repository.ldap[0].order=1

cas.authn.attribute-repository.ldap[0].attributes.uid=uid

cas.authn.attribute-repository.ldap[0].attributes.cn=commonName

cas.authn.attribute-repository.ldap[0].attributes.memberOf=memberOf

cas.authn.attribute-repository.ldap[0].attributes.dn=dn

cas.authn.attribute-repository.ldap[0].attributes.inetUserStatus=inetUserStatus

cas.authn.attribute-repository.ldap[0].ldapUrl=ldap://100.10.1.230:3131

cas.authn.attribute-repository.ldap[0].useSsl=false

cas.authn.attribute-repository.ldap[0].useStartTls=false

cas.authn.attribute-repository.ldap[0].baseDn=o=isp

cas.authn.attribute-repository.ldap[0].searchFilter=uid={0}

cas.authn.attribute-repository.ldap[0].bindDn=xxxxxx

cas.authn.attribute-repository.ldap[0].bindCredential=xxxx

cas.person-directory.return-null=false

cas.person-directory.principal-attribute=uid

cas.authn.attribute-repository.expiration-time=-1

cas.authn.attribute-repository.maximum-cache-size=0

cas.authn.attribute-repository.merger=MERGE

[Ray Bon]

Colin,

Try this in the logs,

        <!-- DEBUG Found principal attributes [...] for [username]

                   Attribute policy [???] allows release of [...] for [username]

                   Final collection of attributes allowed are: [...] -->

        <AsyncLogger name="org.apereo.cas.services.AbstractRegisteredServiceAttributeReleasePolicy" level="debug"/>

You can set attributes to be released by default (normally no attributes are released),

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

                                          cn, \

                                          sn

Attributes can be set on a per service basis as well. The default set can be turned off on a per service basis.

https://apereo.github.io/cas/6.1.x/integration/Attribute-Release-Policies.html

Ray

-- 

Ray Bon

Programmer Analyst

Development Services, University Systems

2507218831 | CLE 019 | rb...@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.

[Colin Ryan]

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

[Ray Bon]

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

[Colin Ryan]

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....

--
- 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+u...@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.

[Andy Ng]

Hi Colin,

I have take a look into your problem, which is using Radius Authentication and  LDAP attribute, and LDAP attribute don't come up.

I am using CAS 6.1.1 + Freeradius + OpenLDAP as demo, but I think the solution should be applicable to CAS 6.0 and other technology as well.

Before going for the fix, I did some research and deducing:

- LDAP Attribute + other authentication do work (e.g. JSON / REST) ....

- So the problems seems to be Radius Authetication

- I am suspecting that, because Radius Authentication is so deeply coupled with MFA, if we don't enabled MFA Radius will have weird behavior.

After some trail and error, here what I did to make LDAP attribute appears:

- In here https://github.com/apereo/cas/blob/v6.1.1/support/cas-server-support-radius/src/main/java/org/apereo/cas/config/RadiusConfiguration.java#L168

plan.registerAuthenticationHandler(radiusAuthenticationHandler());

Change it to

plan.registerAuthenticationHandlerWithPrincipalResolver(radiusAuthenticationHandler(), defaultPrincipalResolver.getObject());

And add defaultPrincipalResolver back to the file:

    @Autowired

    @Qualifier("defaultPrincipalResolver")

    private ObjectProvider<PrincipalResolver> defaultPrincipalResolver;

And... after that change, as you can see in the below capture, I can login with Radius Authentication and also output LDAP Attribute.

I am using hard coded method to fix the above, you should use more elegant way to fix it, or better yet submit a PR to CAS to fix the source of problem :)

If you have docker installed, I have also a github branch here: 

https://github.com/NgSekLong/SelectUrCAS/tree/test_radius_problem_20191107

Which contain the fixed version demo for your testing.

You can see the demo after cloning the above repository, and execute the below Command to generate the demo:

docker-compose -f docker-compose.yml -f ./source/authentication/freeradius/docker-compose.yml -f ./source/authentication-attribute/openldap/docker-compose.yml -f ./source/client/phpcas/docker-compose.yml -f ./source/service-registry/json-1001/docker-compose.yml up

Go to https://127.0.0.1:8443/cas/login

casuser:Mellon

Should see the result

See if the above helps you...

Cheers!

- Andy

[Colin Ryan]

Andy,

Seems almost like your "issue" with the mysterious tight linkage to MFA and Radius and this are related.

Is there a way to enable MFA radius but have it behave as a single factor?

Side note is there a way using Radius Authentication to dynamically add a realm identifier to the users provided userID on a user by users basis..

Colin

Go to Total Mail Defense warning: numerical links are often malicious: https://127.0.0.1:8443/cas/login

casuser:Mellon

Should see the result

See if the above helps you...

Cheers!

- Andy

--
- 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+u...@apereo.org.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/ddc3147f-cbe2-4bd8-a349-38b88df25115%40apereo.org.