portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From FloƟmann Christoph <Christoph.Flossm...@volke-muc.de>
Subject RE: Login mechanism
Date Wed, 07 Jul 2004 07:01:02 GMT
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:patrick@wudika.de]
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.


To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message