LDAP return attributes

554 views
Skip to first unread message

Josep Manel Andrés

unread,
May 4, 2016, 6:47:45 AM5/4/16
to CAS Community
Hi all,

I've been trying to understand how attribute mapping works on cas, but I
am missing something.
So far I found this bean on deployerConfigContext.xml:

<bean id="ldapAuthenticationHandler"
class="org.jasig.cas.authentication.LdapAuthenticationHandler"
p:principalIdAttribute="uid"
c:authenticator-ref="authenticator">
<property name="principalAttributeMap">
<map>
<!--
| This map provides a simple attribute resolution
mechanism.
| Keys are LDAP attribute names, values are CAS
attribute names.
| Use this facility instead of a PrincipalResolver
if LDAP is
| the only attribute source.
-->
<entry key="uid" value="uid" />
<entry key="member" value="member"/>
<entry key="displayName" value="displayName"/>
<entry key="groups" value="groups"/>
<entry key="mail" value="mail"/>
</map>
</property


In which I've added "mail" attribute.
Then, on the same file, I have:

<!--
Bean that defines the attributes that a service may return. This
example uses the Stub/Mock version. A real implementation
may go against a database or LDAP server. The id should remain
"attributeRepository" though.
+-->
<bean id="attributeRepository"
class="org.jasig.services.persondir.support.NamedStubPersonAttributeDao"
p:backingMap-ref="attrRepoBackingMap" />

<util:map id="attrRepoBackingMap">
<entry key="uid" value="uid" />
<entry key="eduPersonAffiliation" value="eduPersonAffiliation" />
<entry key="groupMembership" value="groupMembership" />
<entry>
<key><value>memberOf</value></key>
<list>
<value>faculty</value>
<value>staff</value>
<value>org</value>
</list>
</entry>
</util:map>


And then on cas-services/WEB-INF/managementConfigContext.xml there are
some entries which I don't really understand what they do, when I add a
attribute , it appears on the web interface, but nothing is being passed
to the CAS client:

<!--
Bean that defines the attributes that a service may return. This
example uses the Stub/Mock version. A real implementation
may go against a database or LDAP server. The id should remain
"attributeRepository" though.
-->
<bean id="attributeRepository"

class="org.jasig.services.persondir.support.StubPersonAttributeDao"
p:backingMap-ref="backingMap">
</bean>

<util:map id="backingMap">
<entry key="uid" value="uid"/>
<entry key="eduPersonAffiliation" value="eduPersonAffiliation"/>
<entry key="groupMembership" value="groupMembership"/>
<entry key="mail" value="mail"/>
</util:map>


I've tried to go over the oficial documentations but still is not clear
to me, can anyone give me a hint on this, please?

Thank you!


This is what the cas client gets always:

D, [2016-05-04T12:32:04.730895 #16991] DEBUG -- : CAS server responded
with #<Net::HTTPOK 200 OK readbody=true>:




<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationSuccess>
<cas:user>jandres</cas:user>


</cas:authenticationSuccess>
</cas:serviceResponse>




--
Josep Manel Andrés (josep....@bsc.es)
Operations - Barcelona Supercomputing Center
C/ Jordi Girona, 31 http://www.bsc.es
08034 Barcelona, Spain Tel: +34-93-405 42 14
e-mail: sys...@bsc.es Fax: +34-93-413 77 21
-----------------------------------------------

WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.

http://www.bsc.es/disclaimer

David Abney

unread,
May 4, 2016, 12:33:55 PM5/4/16
to Josep Manel Andrés, CAS Community
Josep,

I have some suggestions that might help you get attributes from LDAP. Warning: I'm currently on CAS 4.0.7 and LDAP was our only source for attributes, so your settings might differ.

Under the authenticationManager bean I would make sure the IdapAuthenticationHandler has value="#{null}". I had value-ref="primaryPrincipalResolver" and I was told, "you either use the attribute repository (and the associated resolver it’s linked to), or you use the authentication handler directly. Right now, you have declared them both. When you do this, your attribute repository/resolver takes precedence, which means you get static [stubbed] hardcoded attribute values."

Example:
<bean id="authenticationManager" class="org.jasig.cas.authentication.PolicyBasedAuthenticationManager">
<constructor-arg>
<map>
<!--
| IMPORTANT
| Every handler requires a unique name.
| If more than one instance of the same handler class is configured, you must explicitly
| set its name to something other than its default name (typically the simple class name).
-->
<entry key-ref="proxyAuthenticationHandler" value-ref="proxyPrincipalResolver" />
<entry key-ref="ldapAuthenticationHandler" value="#{null}" />
</map>
</constructor-arg>

When you set value="#{null}", the attributeRepository and attrRepoBackingMap settings will not be used. It will use the attribute resolution used in the ldapAuthenticationHandler. So, you can ignore those settings and just add the mail value to the ldapAuthenticationHandler, like you did. A more knowledgeable CAS user can correct me if I'm wrong.

Also, do you have the attributes you want to return set as allowed attributes for the registered service? If you wanted to return mail, mail would have to be listed as an allowedAttribute for that service.

Example:
<bean class="org.jasig.cas.services.RegexRegisteredService">
<property name="id" value="1" />
<property name="name" value="Service" />
<property name="description" value="Service Description" />
<property name="serviceId" value="Service Url />
<property name="evaluationOrder" value="1" />
<property name="allowedAttributes">
<list>
<value>displayName</value>
<value>mail</value>
</list>
</property>
</bean>

Finally, if the client is using the CAS 2.0 protocol, it does not return attributes. The CAS 3.0 protocol returns attributes through the /p3/serviceValidate response.

Hope this helps.

––––––––––––––––––––
David Abney
--
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 post to this group, send email to cas-...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/5729D34C.8030401%40bsc.es.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

Josep Manel Andrés

unread,
May 20, 2016, 9:26:19 AM5/20/16
to cas-...@apereo.org
Hi David,
Thanks for your help!
Yes, we also have LDAP as the only authentication source.

On 04/05/16 18:33, David Abney wrote:
Josep,

I have some suggestions that might help you get attributes from LDAP. Warning: I'm currently on CAS 4.0.7 and LDAP was our only source for attributes, so your settings might differ.
I did those changes that you suggested  but it didn't work, it does compile and authenticate, but nothing happens. And for 4.2 it doesn't even start the app.
here is my deployer.

http://pastebin.com/W26pVZTG


Under the authenticationManager bean I would make sure the IdapAuthenticationHandler has value="#{null}".  I had value-ref="primaryPrincipalResolver" and I was told, "you either use the attribute repository (and the associated resolver it’s linked to), or you use the authentication handler directly. Right now, you have declared them both. When you do this, your attribute repository/resolver takes precedence, which means you get static [stubbed] hardcoded attribute values."

Example:
 <bean id="authenticationManager" class="org.jasig.cas.authentication.PolicyBasedAuthenticationManager">
        <constructor-arg>
            <map>
                <!--
                   | IMPORTANT
                   | Every handler requires a unique name.
                   | If more than one instance of the same handler class is configured, you must explicitly
                   | set its name to something other than its default name (typically the simple class name).
                   -->
                <entry key-ref="proxyAuthenticationHandler" value-ref="proxyPrincipalResolver" />
                <entry key-ref="ldapAuthenticationHandler" value="#{null}" />
            </map>
        </constructor-arg>

When you set value="#{null}", the attributeRepository and attrRepoBackingMap settings will not be used.  It will use the attribute resolution used in the ldapAuthenticationHandler.  So, you can ignore those settings and just add the mail value to the ldapAuthenticationHandler, like you did.  A more knowledgeable CAS user can correct me if I'm wrong.

Also, do you have the attributes you want to return set as allowed attributes for the registered service? 

Attached is the screenshot, I think I do have them

If you wanted to return mail, mail would have to be listed as an allowedAttribute for that service.

Example:
<bean class="org.jasig.cas.services.RegexRegisteredService">
            <property name="id" value="1" />
            <property name="name" value="Service" />
            <property name="description" value="Service Description" />
            <property name="serviceId" value="Service Url />
            <property name="evaluationOrder" value="1" />
            <property name="allowedAttributes">
                <list>
                    <value>displayName</value>
                    <value>mail</value>
                </list>
            </property>
</bean>

and the:
opsld03:~ # vi /opt/tomcat/webapps/cas-services/WEB-INF/managementConfigContext.xml

             Bean that defines the attributes that a service may return.  This example uses the Stub/Mock version.  A real implementation
    may go against a database or LDAP server.  The id should remain "attributeRepository" though.
     -->
    <bean id="attributeRepository"
          class="org.jasig.services.persondir.support.StubPersonAttributeDao" p:backingMap-ref="backingMap">
    </bean>

    <util:map id="backingMap">
        <entry key="uid" value="uid"/>
        <entry key="eduPersonAffiliation" value="eduPersonAffiliation"/>
        <entry key="groupMembership" value="groupMembership"/>
        <entry key="mail" value="mail"/>
    </util:map>

    <bean id="serviceRegistryDao" class="org.jasig.cas.services.JsonServiceRegistryDao"
          c:configDirectory="${service.registry.config.location:classpath:services}"/>

    <bean id="auditTrailManager" class="org.jasig.inspektr.audit.support.Slf4jLoggingAuditTrailManager"/>
</beans>



Finally, if the client is using the CAS 2.0 protocol, it does not return attributes.  The CAS 3.0 protocol returns attributes through the /p3/serviceValidate response.
But I think the problem comes here, the clients I am testing the server with they use CAS 2.0 protocol (they used to return attributes with CAS 3.4)

And regarding CAS 3.0 protocol and /p3/serviceValidate I have no idea, I wouldn't know how to proceed with this. What about if I am using cas clients that I can only force them to use protocol 2 but I want them to get all the attributes?


Best regards and thanks a lot!!!



Hope this helps.

––––––––––––––––––––
David Abney
Reply all
Reply to author
Forward
0 new messages