So you say that just importing the jetspeed schema, populating with the ldif and changing the properties won't be a solution for me?
-----Original Message----- From: Patrick von der Hagen [mailto:[EMAIL PROTECTED] Sent: Monday, July 05, 2004 8:49 PM To: Jetspeed Developers List Subject: Re: Login mechanism Flo?mann Christoph wrote: > Hi everyone, Hi Christoph. > I'm trying configure/change the login mechansim. I want jetspeed to get the user > information from an Active Directory via LDAP. > My first question: What files are responsible for the default login module in > jetspeed? > I didn't find them yet. > Second: Has anyone made some experiences with LDAP and jetspeed? Well, I'm currently working with jetspeed and LDAP and I'm not very happy about it. Probably someone just had a look at the sql-tables and decided to port it as closely as possible to LDAP. 1. groups Definitions of groups in LDAP do exist, e. g. groupOfNames, groupOfUniqueNames or posixGroup. Currently a user-Attribute is used to list the groups a users is member in. Usually a group-attribute is used to list the users that are members. So jetspeedgroups just don't integrate well with group-definitions you might already have. 2. users They are not that bad. However, they are stored in a "users"-subtree whereas most unix-setups I've seen choose "people" instead. I don't know if AD uses "people", "users" or something entirely different, but it should at least be configurable and not hard-coded. I'd even prefer to ommit a dedicated users-subtree entirely to enable a (still simple) setup like ou=users,ou=department1,BASE and ou=users,ou=department2,BASE with one simple search starting at BASE. 3. passwords Jetspeed reads the userPassword-entry from LDAP and compares it to the password entered by the user. Usual LDAP-behaviour IMHO should be to search the user-dn in LDAP and try to bind as that dn with the given password. If the bind is successful, the user is authenticated and rejected otherwise. The current solution needs to much privileges (read instead of auth) and unnecessarily limits the choice of avaliable password-hashes. By the way, the source says // Store the clear-text password to session if some of the // portlets need it (for example to single-signon functionality) user.setTemp( "sessionPassword", password ); but of course all portlets expect the cleartext-password as "password" instead of "sessionPassword". But if you choose encrypted passwords, the crypted string is returned by user.getPassword(), which of course does not help since in my experience all applications or portlets expect cleartext passwords. So I tryed to store the crypted password as sessionPassword and the cleartext password in user.setPassword. However, after modifying user.save() to use "sessionPassword" instead of "password" it just stored an empty string to LDAP, I haven't yet sorted out why... Oh, by the way, I had a problem with LDAP and rule-management, but I haven't had time to investigate wheter I just have a bad understanding of jetspeed-roles or if LDAP is broken there. I'm just the LDAP-admin, not the portal-guy. I created a new role "restriceduser", only allowed to view (like guest"). However, all users assigned this role still have permissions like "users". Is this a jetspeed-default or a LDAP-problem? I might release some LDAP-patches when everything is worked out, but since there is no LDAP-support in jetspeed 1.5 few people seem to care. -- CU, Patrick. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
