topic Re: Alfresco 1.4, ACEGI,CAS SSO and LDAP integration.Help needed in Alfresco Archive

Alfresco 1.4, ACEGI,CAS SSO and LDAP integration.Help needed

pakin — Wed, 03 Jan 2007 09:19:05 GMT

Hi all alfresco integrators,This is a call to those developers or integrators that have or have had the same need than me which is the topic subject. Both those that have been successful in this task and those that are still looking for a solution, are invited to collaborate. I think there is a lot

Re: Alfresco 1.4, ACEGI,CAS SSO and LDAP integration.Help needed

pakin — Wed, 03 Jan 2007 13:04:29 GMT

Complete scenario:

We have a JA-SIG Central Authentication Service (CAS) service perfectly running that is using an Active Directory LDAP to perform authentication. This service is working perfectly because we currently have several applications with their authentication integrated with CAS using the ACEGI CAS Adapter. The problems came up when we wanted integrate CAS authentication with Alfresco using the ACEGI CAS Adapter.

First we begin to research what do we need to integrate CAS with Alfresco, so let me show you what we have thought about the general tasks that we must tackle to achieve our goal and correct me if I'm wrong, please:

   1. First of all we have to import users and groups from LDAP to Alfresco database.
   2. Integrate the ACEGI CAS Processing filter to manage the SSO ticket generated by CAS.
   3. Create another filter which using the ACEGI Security Context to get the user and password information, it'll perform all the tasks that must be done in the Alfresco authentication.

Well, now I'm going to specify the version of the programs and libraries I'm using:

    * Java 1.5.0_05
    * Tomcat 5.5.20
    * PostgreSQL 8.0.4
    * Alfresco 1.4 Community Edition
    * CAS 3.0.5
    * Acegi Security 0.8.2 patched which comes with the Alfresco 1.4 distribution
    * maybe I'm forgetting something

In the next post I'll put the steps to perform the first task.

See you later, and don't forget to reply if you see something wrong. Thanks a lot

Regards, Pakin

Re: Alfresco 1.4, ACEGI,CAS SSO and LDAP integration.Help needed

pakin — Fri, 05 Jan 2007 10:35:39 GMT

Task1: LDAP import user and groups and ldap authentication:

I assume that you have started the default Alfresco war distribution without problems. The only thing that I'd do before going on, is to create an space called "Users" inside the "company_home" space. The reason is because I want to import all the LDAP users into that folder to have them better organized. For this task I've followed this post:

http://forums.alfresco.com/viewtopic.php?t=4666&highlight=ldap

To accomplish this first task, all we need to do is to modify three files, as well as having a working LDAP service (Note: All my files are prepared for an Active Directory LDAP):

   1. ldap-authentication-context.xml: this file has to be located at "…/WEB-INF/classes/alfresco/extension/", if not, look for it at your alfresco distribution with the name: "ldap-authentication-context.xml.sample".
   2. file-servers.xml: this file has to be located at "…/WEB-INF/classes/alfresco/". I don't understand why, but there is no mention about this file in the wiki section that explains LDAP sync with Alfresco :?
   3. authentication-service-context.xml: this file has to be located at "…/WEB-INF/classes/alfresco/", but you only have to modify it if you have created the "Users" space as I've suggested before.

I have uploaded the files into this location for anyone who wants them:

http://www.box.net/public/xcvloz04fc

Anyway, I'll try to explain what have I changed in the files, but always considering that many of the changes are "environment depending":

   1. Changes in ldap-authetication-context.xml: I've only put the changed beans.

   ….

    <!–
   
    This bean is used to support general LDAP authentication. It is also used to provide read only access to users and groups
    to pull them out of the LDAP reopsitory
   
    –>
   
    <bean id="ldapInitialDirContextFactory" class="org.alfresco.repo.security.authentication.ldap.LDAPInitialDirContextFactoryImpl">
        <property name="initialDirContextEnvironment">
            <map>
                <!– The LDAP provider –>
                <entry key="java.naming.factory.initial">
                    <value>com.sun.jndi.ldap.LdapCtxFactory</value>
                </entry>
               
                <!– The url to the LDAP server –>
                <!– Note you can use space separated urls - they will be tried in turn until one works –>
                <!– This could be used to authenticate against one or more ldap servers (you will not know which one ….) –>
                <entry key="java.naming.provider.url">
                    <value>ldap://???.???.???.???:389</value>
                </entry>
               
                <!– The authentication mechanism to use      –>
                <!– Some sasl authentication mechanisms may require a realm to be set –>
                <!–                java.naming.security.sasl.realm –>
                <!– The available options will depend on your LDAP provider –>
                <entry key="java.naming.security.authentication">
                    <value>simple</value>
                </entry>
               
                <!– The id of a user who can read group and user information –>
                <!– This does not go through the pattern substitution defined above and is used "as is" –>
                <entry key="java.naming.security.principal">
                    <value>user</value>
                </entry>
               
                <!– The password for the user defined above –>
                <entry key="java.naming.security.credentials">
                    <value>password</value>
                </entry>
            </map>
        </property>
    </bean>

    ….

    <!– Extract user information from LDAP and transform this to XML –>
   
    <bean id="ldapPeopleExportSource" class="org.alfresco.repo.security.authentication.ldap.LDAPPersonExportSource">
        <!–
        The query to select objects that represent the users to import.
       
        For Open LDAP, using a basic schema, the following is probably what you want:
        (objectclass=inetOrgPerson)
       
        For Active Directory:
        (objectclass=user)
        –>
        <property name="personQuery">
            <value>(objectclass=user)</value>
        </property>
       
        <!–
        The seach base restricts the LDAP query to a sub section of tree on the LDAP server.
        –>
        <property name="searchBase">
            <value>ou=General,dc=sf,dc=local</value>
        </property>
       
        <!–
        The unique identifier for the user.
       
        THIS MUST MATCH WHAT THE USER TYPES IN AT THE LOGIN PROMPT   
       
        For simple LDAP authentication this is likely to be "cn" or, less friendly, "distinguishedName"
       
        In OpenLDAP, using other authentication mechanisms "uid", but this depends on how you map
        from the id in the LDAP authentication request to search for the inetOrgPerson against which
        to authenticate.
       
        In Active Directory this is most likely to be "sAMAccountName"
       
        This property is mandatory and must appear on all users found by the query defined above.
       
        –>
        <property name="userIdAttributeName">
            <value>sAMAccountName</value>
        </property>
       
        <!– Services –>
        <property name="LDAPInitialDirContextFactory">
            <ref bean="ldapInitialDirContextFactory"/>
        </property>
        <property name="personService">
            <ref bean="personService"></ref>
        </property>
        <property name="namespaceService">
            <ref bean="namespaceService"/>
        </property>
       
        <!–
        This property defines a mapping between attributes held on LDAP user objects and
        the properties of user objects held in the repository. The key is the QName of an attribute in
        the repository, the value is the attribute name from the user/inetOrgPerson/.. object in the
        LDAP repository.    
        –>
        <property name="attributeMapping">
            <map>
                <entry key="cm:userName">
                    <!– Must match the same attribute as userIdAttributeName –>
                    <value>sAMAccountName</value>
                </entry>
                <entry key="cm:firstName">
                    <!– OpenLDAP: "givenName" –>
                    <!– Active Directory: "givenName" –>
                    <value>givenName</value>
                </entry>
                <entry key="cm:lastName">
                    <!– OpenLDAP: "sn" –>
                    <!– Active Directory: "sn" –>
                    <value>sn</value>
                </entry>
                <entry key="cm:email">
                    <!– OpenLDAP: "mail" –>
                    <!– Active Directory: "???" –>
                    <value>mail</value>
                </entry>
                <entry key="cm:organizationId">
                    <!– OpenLDAP: "o" –>
                    <!– Active Directory: "???" –>
                    <value>ou</value>
                </entry>
                <!– Always use the default –>
                <entry key="cm:homeFolderProvider">
                    <null/>
                </entry>
            </map>
        </property>
        <!– Set a default home folder provider –>
        <!– Defaults only apply for values above –>
        <property name="attributeDefaults">
            <map>
                <entry key="cm:homeFolderProvider">
                    <value>personalHomeFolderProvider</value>
                </entry>
            </map>
        </property>
    </bean>

    ….

    <!– Extract group information from LDAP and transform this to XML –>

    <bean id="ldapGroupExportSource" class="org.alfresco.repo.security.authentication.ldap.LDAPGroupExportSource">
        <!–
        The query to select objects that represent the groups to import.
       
        For Open LDAP, using a basic schema, the following is probably what you want:
        (objectclass=groupOfNames)
       
        For Active Directory:
        (objectclass=group)
        –>
        <property name="groupQuery">
            <value>(objectclass=group)</value>
        </property>
       
        <!–
        The seach base restricts the LDAP query to a sub section of tree on the LDAP server.
        –>
        <property name="searchBase">
            <value>ou=General,dc=sf,dc=local</value>
        </property>
       
        <!–
        The unique identifier for the user. This must match the userIdAttributeName on the ldapPeopleExportSource bean above.
        –>
        <property name="userIdAttributeName">
            <value>sAMAccountName</value>
        </property>
       
        <!–
        An attribute that is a unique identifier for each group found.
        This is also the name of the group with the current group implementation.
        This is mandatory for any groups found.
       
        OpenLDAP: "cn" as it is mandatory on groupOfNames
        Active Directory: "cn"
       
        –>
        <property name="groupIdAttributeName">
            <value>cn</value>
        </property>
       
        <!–
        The objectClass attribute for group members.
        For each member of a group, the distinguished name is given.
        The object is looked up by its DN. If the object is of this class it is treated as a group.
        –>
        <property name="groupType">
            <value>organizationalUnit</value>
        </property>
       
        <!–
        The objectClass attribute for person members.
        For each member of a group, the distinguished name is given.
        The object is looked up by its DN. If the object is of this class it is treated as a person.
        –>
        <property name="personType">
            <value>person</value>
        </property>
        <property name="LDAPInitialDirContextFactory">
            <ref bean="ldapInitialDirContextFactory"/>
        </property>
        <property name="namespaceService">
            <ref bean="namespaceService"/>
        </property>
       
        <!–
        The repeating attribute on group objects (found by query or as sub groups)
        used to define membership of the group. This is assumed to hold distinguished names of
        other groups or users/people; the above types are used to determine this.
       
        OpenLDAP: "member" as it is mandatory on groupOfNames
        Active Directory: "member"
       
        –>
        <property name="memberAttribute">
            <value>member</value>
        </property>
       
        <property name="authorityDAO">
            <ref bean="authorityDAO"/>
        </property>
    </bean>

    ….
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

    The other changes in this file are relative to the ldapPeopleTrigger and ldapGroupTrigger where I've changed the "startDelay" property to 10000 milliseconds and where is VERY IMPORTANT to dis-comment the "scheduler" property in both beans.

   2. Changes in file-servers.xml: all you have to do is change this definition

    <config evaluator="string-compare" condition="Filesystem Security">
        <authenticator type="alfresco">
        </authenticator>
    </config>‍‍‍‍

    <config evaluator="string-compare" condition="Filesystem Security">
        <authenticator type="passthru">
              <Server>???.???.???.???</Server>
        </authenticator>
    </config>‍‍‍‍‍

where ???.???.???.??? is the LDAP server IP, which should be the same defined in the file before. I don't know exactly what have we done with this step but is necessary . If someone can tell me, it would be appreciated.

3. Changes in authentication-service-context.xml: remember!!, only if you have created the "Users" space. The change is only at the personalHomeFolderProvider bean, which must be as follows:

   ….

    <bean name="personalHomeFolderProvider" class="org.alfresco.repo.security.person.UIDBasedHomeFolderProvider">
        <property name="serviceRegistry">
            <ref bean="ServiceRegistry" />
        </property>
        <property name="path">
           <value>/${spaces.company_home.childname}/cm:Users</value>
        </property>
        <property name="storeUrl">
           <value>${spaces.store}</value>
        </property>
        <property name="homeFolderManager">
            <ref bean="homeFolderManager" />
        </property>
        <property name="inheritsPermissionsOnCreate">
            <value>false</value>
        </property>
        <property name="ownerPemissionsToSetOnCreate">
            <set>
                <value>All</value>
            </set>
        </property>
        <property name="userPemissions">
            <set>
                <value>All</value>
            </set>
        </property>
    </bean>

    …
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Well, that's all by now. Soon I'll put the steps to achieve task 2. The problems will begin on task 3

Regards pakin.

Re: Alfresco 1.4, ACEGI,CAS SSO and LDAP integration.Help needed

croffler — Mon, 08 Jan 2007 22:13:38 GMT

I need to integrate CAS with Alfresco …. keep up the good work

One of my concerns … the ldap synchronization; I might have potentialy thousands of users in ldap. From what I can see the users will be created regardless if they use the system or not…..is this correct ?

I am using Liferay and OTRS, what they do : the account get's only created if the user logs in. Can this be done somehow in Alfresco ?

Chris

Re: Alfresco 1.4, ACEGI,CAS SSO and LDAP integration.Help needed

aleclanter — Tue, 09 Jan 2007 21:24:35 GMT

Glad someone else is working on Alfresco/CAS/LDAP. I've been struggling with this for integration with Liferay, so if I make any progress before you've updated this post, I may throw my own two cents worth up here.

Keep up the good work, and thanks!

Re: Alfresco 1.4, ACEGI,CAS SSO and LDAP integration.Help needed

croffler — Tue, 09 Jan 2007 21:35:17 GMT

My big concern is the synchronization… as I said I have potentialy 100K users and I can't synchronize ldap with Alfresco all the time

Re: Alfresco 1.4, ACEGI,CAS SSO and LDAP integration.Help needed

aleclanter — Wed, 10 Jan 2007 17:05:59 GMT

My big concern is the synchronization… as I said I have potentialy 100K users and I can't synchronize ldap with Alfresco all the time

I agree. After testing out the ldap synch with our production ldap tree (ActiveDirectory, actually), this just isn't going to work. I'm going to look into writing a custom login module that simply imports successfully authenticated users from ldap as they sign in. If anyone finds a post related to that, please PM it to me; I've searched and come up blank.

Re: Alfresco 1.4, ACEGI,CAS SSO and LDAP integration.Help needed

ribz33 — Wed, 10 Jan 2007 17:31:00 GMT

To help, i think there is this post close to your problem :
http://forums.alfresco.com/viewtopic.php?t=4379

Re: Alfresco 1.4, ACEGI,CAS SSO and LDAP integration.Help needed

croffler — Wed, 17 Jan 2007 07:48:09 GMT

I looked some more at this stuff….. I think the best way is to use the Web Services to do the CRUD for the users.
I have an admin Java application that maintains the users in LDAP. Upon a modification in LDAP I am planing to update Alfresco with this info via Web Services or the Java Service API

Has anyone done this ?

Chris

Re: Alfresco 1.4, ACEGI,CAS SSO and LDAP integration.Help needed

sagui — Fri, 08 Jun 2007 14:14:29 GMT

Thanks pakin for the nice post.

We are trying to joint CAS with Alfresco integrated by Liferay. We have liferay 4.2.1, Alfresco 1.4 and JA-SIG CAS 3.0.7. CAS service is using an ApacheDS 1.0.1 (LDAP) to perform authentication. CAS works fine for Liferay, but not with Alfresco.

We get the following error:

â€œCIFS server configuration error, Wrong authentication setup for passthru authenticator (can only be used with LDAP/JAAS auth component)
org.alfresco.error.AlfrescoRuntimeException: Wrong authentication setup for passthru authenticator (can only be used with LDAP/JAAS auth component)â€

Regarding the general tasks to integrate CAS with Alfresco, please could you tell us the steps to perform the second and third tasks?

Thanks in advance. Any help would be greatly appreciated!

Re: Alfresco 1.4, ACEGI,CAS SSO and LDAP integration.Help needed

frank_s — Mon, 12 May 2008 10:41:32 GMT

I've been struggling to implement a setup like this (albeit using Alfresco 2.9B) for quite a while now and have so far failed to get anywhere.

Having read this thread, I have to admit that I'm thoroughly confused. You talk about CAS/SSO, but at the same time you describe the import of user information from an LDAP server. Isn't one of the points of using CAS that you don't have to store and maintain user data on these systems?

The way I've understood CAS/SSO to work is that the application redirects to the CAS server, which then binds to the LDAP server and establishes credentials of the user that way. The only things to get passed back and forth between the application (i.e. Alfresco) and the CAS server should be service tickets.

It seems to me what you're configuring is an LDAP authentication - could someone please fill me in on what I am missing?

f.

Re: Alfresco 1.4, ACEGI,CAS SSO and LDAP integration.Help needed

mikewaters — Wed, 21 May 2008 17:32:26 GMT

Hi Frank

The username also gets passed between the CAS server and the app, so that the app knows who is making the request and can act accordingly.
There are 2 parts to (S)SO - authenitcation (is the user who they say they are, which CAS handles) and authorisation - ie what is the user allowed to do or see.

The latter requires the app to know about the user's roles and permissions which are not given to it by CAS - all it gets is a username so Alfresco has to have the users set up in advance of the request so there is (in the case of Alfresco) a home space ready and waiting for the user and the user is a member of the correct roles etc to see restricted content.

The thread discusses how to do this -

One way of doing this is to read a single user's data from LDAP on the fly when a user request hits the filters and translate that into alfresco data just before the request gets to alfresco "proper". This might be slow and takes away some of the point of using CAS (might as well authenticate with LDAP at the same time)

The other way is to import all the user data ahead of time, but then you might be doing unneccessary work.

Shibboleth attempts to address these issues by passing more than just the username at the time of authentication.

hth

-Mike