0

I have the same problem as several other questions here, none of which have really been answered; that is, with CAS 4.x (4.2.6 actually) I cannot get LDAP attributes to return to the client application.

Question 1 This seems like overkill; custom code to get around what is a "simple" problem.

Question 2 Had already done this, and it didn't work.

So, now it's my turn to ask... is there some magic to making it work? We've used 3.5 for a long time without any issues. I'm trying to convert those settings to the 4.x Maven overlayer and new context configuration of 4.x, and it's not doin' it.

I can see in the logs that CAS is requesting, and getting the properties I'm looking for from LDAP. But they are not getting put in the token back to the application.

What more needs to be done beyond what the Apereo documentation lays out? I'm thinking it's the attribute repository maybe??? If something would help you help me through this, just ask: Config, Logs (redacted of course)... anything.

Thanks.

Update #1. Here is my resolvers list. NOTE: I keep code/settings in place commented out until I get it to work before I clean stuff out.

<util:map id="authenticationHandlersResolvers">
    <!--
    <entry key-ref="proxyAuthenticationHandler" value-ref="proxyPrincipalResolver" />
    <entry key-ref="primaryAuthenticationHandler" value-ref="primaryPrincipalResolver" />
    -->
    <!--<entry key-ref="ldapAuthenticationHandler" value-ref="primaryPrincipalResolver" /> -->
    <entry key-ref="ldapAuthenticationHandler" value="#{null}" />
</util:map>

Update #2

I've done more testing, and still am unsuccessful. I think, it's coming down to the principalAttributeMap of the LdapAuthenticationHandler not working, OR, the attributeReleasePolicy of the serviceRegistryDao... anyone see any issues in this config?

<bean id="ldapAuthenticationHandler" class="org.jasig.cas.authentication.LdapAuthenticationHandler"
    p:principalIdAttribute="sAMAccountName"
    c:authenticator-ref="authenticator" 
    >
    <property name="principalAttributeMap">
        <map>
            <entry key="cn" value="cn" />
            <entry key="mail" value="Email" />
            <entry key="memberOf" value="Groups" />
            <entry key="displayName" value="displayName" />
        </map>
    </property>
</bean>

<bean id="serviceRegistryDao" class="org.jasig.cas.services.InMemoryServiceRegistryDaoImpl">
    <property name="registeredServices">
        <list>
            <bean class="org.jasig.cas.services.RegexRegisteredService"
                  p:id="5" 
                  p:name="All Servicesxxx" 
                  p:description="Allow connections for all services and protocols"
                  p:serviceId="^(http|https|imaps)://.*" 
                  p:evaluationOrder="5"  
                  >
                <property name="attributeReleasePolicy">
                    <bean class="org.jasig.cas.services.ReturnAllAttributeReleasePolicy" />
                </property>
            </bean>
        </list>
    </property>
</bean>
Community
  • 1
  • 1
Jason Nethercott
  • 373
  • 3
  • 20
  • Did you do the #{null} thing as told in the second question? I recommend you not using the JSON. This caused problems on my CAS server. Check my answer to my question (question 1) and see if it helps you. – yemerra Oct 12 '16 at 11:41
  • Yes, I have done the #{null} change in the Authentication Handler Resolvers list. It didn't help. – Jason Nethercott Oct 12 '16 at 12:41
  • I answered my question (question 1). Everything I wrote there works for me except the thing i discribed. Do you use this file? – yemerra Oct 12 '16 at 12:52
  • I was not having an issue with the registered services configuration, I thought. So first, I updated my service to use the ReturnAllAttributeReleasePolicy, but that didn't work. Then I changed my deployer context to remove the jsonServiceRegistryDao and replace it with your sample: InMemoryServiceRegistryDaoImpl. Still not working. I do know it's using the new registration because the name and description shows up in the CAS screen when authenticating. – Jason Nethercott Oct 12 '16 at 19:04
  • This is a stretch... but could it be, that because I'm not running the war in a secure nature? I have my registered service setup as: "^(http|https|imaps)://.*".... For QA and production is will be secure, but for dev it's not. – Jason Nethercott Oct 12 '16 at 19:10
  • Yes, CAS requires you to use HTTPS. It is only possible to use HTTP if you change the seetings. For example, if disabled, cookies wont be created if you don't use a secure connection (HTTPS) – yemerra Oct 12 '16 at 19:21
  • yea... we always had it working. CAS itself is https in production, but it's the support for https or http apps. I guess I could try throwing this new version in a https secure environment to see if my problem goes away... I have to be missing something... I just don't get it. – Jason Nethercott Oct 12 '16 at 21:01

1 Answers1

0

To quote from CAS Security Guide:

All communication with the CAS server MUST occur over a secure channel (i.e. TLSv1). There are two primary justifications for this requirement:

  1. The authentication process requires transmission of security credentials.
  2. The CAS ticket-granting ticket is a bearer token.

Since the disclosure of either data would allow impersonation attacks, it’s vitally important to secure the communication channel between CAS clients and the CAS server.

Practically, it means that all CAS urls must use HTTPS, but it also means that all connections from the CAS server to the application must be done using HTTPS:

  • when the generated service ticket is sent back to the application on the “service” url when a

  • proxy callback url is called.

HTTPS is a must in CAS. However, there are possibilities to disable it but it is highly recommended not to do so. If you have struggle to handle the SSL configuration, I recommend you read my question where I explain in detail how to deal with the keystores.

Community
  • 1
  • 1
yemerra
  • 1,352
  • 4
  • 19
  • 44
  • I have "disabled it" or a better description is: configured CAS to allow authentication of non-secure applications. My goal, right now, is it get it working so that we can then pass it off to a QA group for final testing. Mucking around with security and all that is a pain, mostly because it's hard to do that monitoring to make sure it's working as expected (unit testing). My assumption is that CAS works the same between a secure and non-secure installation; it just cannot be guaranteed to be truly secure if you are dumb enough to have it non-secure in a production capacity. – Jason Nethercott Oct 13 '16 at 18:02
  • Yes, but once you know how to make it run with HTTPS, it isnt that difficult at all. Just read the step by step instructions when the day have come for your product – yemerra Oct 13 '16 at 18:20
  • An update to this: Running on a server that is secured with a valid (not self signed) certs didn't help one bit. The CAS is getting the groups from LDAP (I see them in the logs), but is not sending them forward to the application. I just can't figure out what configuration is wrong. This worked flawlessly with CAS 3. I'm continuing to try different things, but there must be something obvious. – Jason Nethercott Nov 22 '16 at 18:26