teamwork site F.A.Q. suggest a feature blog online demo about
login register currently online users: 9
all roots  : :   teamwork  : :   install and configuration  : :   Using LDAP with teamwork 3.1
Using LDAP with teamwork 3.1
messageauthordate (elaps.)rating (0-10)
Using LDAP with teamwork 3.1
It seems there is no possibility of using LDAP with teamwork 3.1, or is it possible relying on Tomcat auth? anonymous 10 jan 2007 (1331D 7:24) 7
 
We just added HTTP authentication integration in Teamwork. In this way you can enable HTTP authentication on the container (Tomcat, Resin,...), and Teamwork will get the authenticated user from the container context, search by its login name in its people list, and if the user is found and is an enabled one, will not ask to login again in Teamwork.
This new feature will be released in next version, which should be out before the opening of OOP in Munich, January 20, 2007.

This way if you integrated Tomcat with LDAP, this will be bridged to Teamwork. Notice that the rights of the user in Teamwork and the LDAP user are totally disconnected.
Pietro Polsinelli 10 jan 2007 (1331D 4:59) 0
 

Is there any doc with the concrete steps for using ldap relying on container auth? I am trying and seems I could be missing something

TIA


losalo 17 sep 2007 (1081D 10:12) 0
 

After some tests I think there is some issue here. We are using the same params for tomcat that we are currently using in other apps succesfuly configured to auth against LDAP.


1) Trying with tomcat configured to auth against LDAP and BASIC login-config (popup window for us/passwd)

<login-config>
  <auth-method>BASIC</auth-method>
</login-config>

The popup window works ok, us/pass correctly cheched etc. and the teamwork page for this user appears ok.  Log in succesful.
 Problem-> Logoff does not work correctly. We are led to initial teamwork login page that we are supposed not to use any longer.

 There, whatever the usr/pass we typed  (inexistent, blank, correct, etc) we are again lead inside with the same user. Seems that the container session is still alive and no security check is refreshed. The user is probably got from tomcat that still holds the user that have tried to logoff. Seems as the container has not been told to remove session data and logoff redirect has to be changed to not go to teamwork's own login page

2) Trying with <form-login-config> that is what we really want (more secure)

<login-config>
  <auth-method>FORM</auth-method>
   <realm-name></realm-name>
   <form-login-config>
    <form-login-page>/applications/teamwork/security/login.jsp</form-login-page>
    <form-error-page>/applications/teamwork/security/error.jsp</form-error-page>
   </form-login-config>
</login-config>


(our loging page has the format that the std says for container form auth, and it is working in other apps ok)

Seems that there is some mess in the auth-login chain with web.xml filters as the login page is also a .jsp page


The form-login-config is what we really want to use but we do not find a way to do so, and need some help (or fix) here.

Thanks in advance

Carlos Alonso
Universidad Publica de Navarra




losalo 17 sep 2007 (1081D 7:12) 0
 
From the documentation in global settings:

"You can enable HTTP authentication on the container (Tomcat, Resin,...), and Teamwork will get the authenticated user from the container context, search by its login name in its people list, and if the user is found and is an enabled one, will not ask to login again in Teamwork. To enable this feature add in global settings the line ENABLE_HTTP_AUTHENTICATION=yes"

In this cases, LoginAction does

  user = Operator.findByLoginName(request.getRemoteUser());

and logs it in. The filter configured in web.xml that redirects to the login pages is "AccessControlFilter".

In case of logout, the LoginController does this:

      request.getSession().invalidate();

which should kill the current session.

If you want we can send you the sources of the LoginAction and LoginController classes, so you can customize them to your needs.

Pietro Polsinelli 17 sep 2007 (1081D 6:36) 0
 


In your previous message, it could cover the BASIC authentication option (popup window in browser for us/pass). Even in this case see http://www.mail-archive.com/struts-user@jakarta.apache.org/msg75250.html about invalidate (it will not work) So logout is still an issue with BASIC mode.

But the case of form login auth is what we really want as it is the recommended option for container managed auth. As we mentioned before, teamwork could have problem with it as it is based on jsp pages, that seem to be processed with filters like any other jsp pages of the app, messing with the container mechanism. We could be wrong, indeed.
Have you any form based (container auth) install running?
TIA
losalo 18 sep 2007 (1080D 11:45) 0
 
I'm sorry but we do not have form based examples to supply.
we have implementation based on different SSO engines.

In any case:
>  Problem-> Logoff does not work correctly. We are led to initial teamwork login page that we are supposed not to use any longer.

This happens because of the logout action invoked by the login.jsp page. After logout the login page is always shown.

You can change the login page as follows, changing

    pageState.perform(request, response);
    pageState.toHtml(pageContext);

to

    pageState.perform(request, response);
    if (Commands.LOGOUT.equals(pageState.command)) {
      response.sendRedirect("[YOUR LOGOUT PAGE]);
    }
    pageState.toHtml(pageContext);
 

once redirected to [YOUR LOGOUT PAGE] the session has been destroyed, and your page could ask for login again.

Regards

Roberto
Roberto Bicchierai 18 sep 2007 (1080D 7:56) 0
 
Hello everyone,

I am in the last stage of evaluation and so far I love this product. However, it is necessary for me to authenticate against LDAP. I read the post that there is no current documentation but I wanted to find out if someone could point me in the correct direction other than RTFM.

All we want to do is to authenticate the user against LDAP. Nothing fancy. Just make sure that this user, using this password is in our system. No file permissions or special permission checking.

I have been reading the Tomcat documentation about JNDIRealms and I believe that is what I need to achieve but I have had no luck understanding which files I have to edit and what file I have to add. I have read the
>>Realm Configuration How-To
>>Tomcat JNDI Realm @ http://cymulacrum.net/writings/adv_tomcat/c487.html
>>All of the post on this site referring to the term "LDAP"

Any help is appreciated,
Alex
alex 15 nov 2007 (1022D 19:30) 0
 
Hi Alex,

I'm sorry for the delay in replying, but I have tested in deep the solution before answering.

There are many different solutions for configuring Tomcat depending on your ldap structure. We will use a basic approach.


In order to config Tomcat and teamwork to use LDAP follow these steps:



1) edit tomcat configuration file:
[TEAMWORK_ROOT]/conf/server.xml


add a realm definition for ldap adding these lines in section: <GlobalNamingResources>
  <Realm
    className="org.apache.catalina.realm.JNDIRealm" debug="99"
    authentication="simple"
    connectionName="uid=admin,ou=system"
    connectionPassword="secret"
    connectionURL="ldap://localhost:10389"
    userPattern="uid={0},ou=users,ou=system"
    roleBase="ou=groups,ou=system"
    roleName="cn"
    roleSearch="(uniquemember={0})"
    resourceName="TWLDAP"
 />

where “connectionName” parameter is the user’ cn used for querying your ldap and “connectionPassword” is the password (if you need to hide password see http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#Digested%20Passwords)

Then you need to extract your user from ldap specifying a pattern.
In this case "uid={0},ou=users,ou=system" where {0} will be replaced by tomcat during the user authentication phase.
The worst setup step the extraction of user’ roles.
First specify the base of your group:
in our case roleBase="ou=groups,ou=system" then specify the property used to extract the role name; “cn” in our case.

Now you have identified both users and roles: has your user the role? Use “roleSearch” parameter to specify the query. Again the {0} parameter will be replaced.
Remember, this is a basic approach, roles can be extracted differently according to your ldap structure (see references for detail).

Last parameter “resourceName” assigns a name to this realm will be used in the next step.



2) edit the webapp configuration file:
[TEAMWORK_ROOT]/webapps/ROOT/WEN-INF/web.xml


add a security constraint definition to section: <web-app>
  <!-- Define a security constraint on this application -->
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>Entire Application</web-resource-name>
      <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>tw</role-name>

      <!-- Define the login configuration for this application -->
      <login-config>
        <auth-method>BASIC</auth-method>
        <realm-name>TWLDAP</realm-name>
      </login-config>

      <!-- Security roles referenced by this web application -->
      <security-role>
        <description>
          The role that is required to log in to Teamwork
        </description>
        <role-name>tw</role-name>
      </security-role>
    </auth-constraint>
  </security-constraint>
  

In this case I protect the whole web-aspp. Notice that here I refer the role called “tw” that is used in my ldap structure.

Then declare “login-config” parameter instructing tomcat to use the BASIC method and the “TWLDAP” realm previously defined.

Last part is the role declaration.



3) instruct Teamwork to use a http single-sign-on: edit
[TEAMWORK_ROOT]/webapps/ROOT/commons/settings/global.properties


add (or modify)

ENABLE_HTTP_AUTHENTICATION=yes

4) restart Tomcat and try


What it is important to understand is that Teamwork use its own user table. Once the http authentication has been enabled TW extracts the username from the request and query the db finding the username, so you need to populate Teamwork user db before to activate ldap (e.g. you need to have an “uid=administrator” user in your ldap for the TW setup. Guess why :-) ).


In order to be more exhaustive here is the ldif code of my example

  dn: ou=groups,ou=system
  ou: groups
  objectClass: organizationalUnit
  objectClass: top
  dn: cn=tw,ou=groups,ou=system

  objectClass: groupOfUniqueNames
  objectClass: top
  cn: tw
  uniquemember: uid=wscott,ou=users,ou=system
  uniquemember: uid=administrator,ou=users,ou=system

  dn: ou=users,ou=system
  ou: users
  objectClass: organizationalUnit
  objectClass: top

  dn: uid=wscott,ou=users,ou=system
  sn: walter scott
  objectClass: organizationalPerson
  objectClass: person

  objectClass: inetOrgPerson
  objectClass: top
  cn: walter scott
  userpassword: wscott
  uid: wscott
  displayname: Walter Scott


  dn: uid=administrator,ou=users,ou=system
  sn: administrator
  objectClass: organizationalPerson
  objectClass: person
  objectClass: inetOrgPerson

  objectClass: top
  cn: administrator
  userpassword:
  uid: administrator
  displayname:  System Manager

Some good references:
http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#Configuring%20a%20Realm
http://www.linux-sxs.org/internet_serving/c619.html

for ldap on active directory see:
http://forum.java.sun.com/thread.jspa?threadID=672135&messageID=4165493
http://jspwiki.org/wiki/ActiveDirectoryIntegration


I really hope this helps :-) !


Cheers,

Roberto

Roberto Bicchierai 16 nov 2007 (1021D 8:05) 0
 
In Teamwork 3.2.9 we have released native LDAP integration: see here .
Teamwork Staff 26 sep 2008 (706D 8:27) 0