| message | author | date (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 |
| | |