hi,
*I think then that this behaviour should be switchable in config: having a
parameter that decides weither or not OM falls back to internal DB auth if
Ldap is offline.*
=> adding this param is no problem, you can also make it slightly different:
Still populate the password but if the user has turned off the LDAP Feature
you set the user to status *disabled*. Disabled users are not able to login
via the User-Database of OM.
Sebastian
2010/4/15 <t.lem...@gmail.com>
> smoeker a écrit :
>
> hola,
>>
>> the original reason for storing the ldap passwd locally (md5
>> encrypted) within OM is to be able to use openMeetings, even if ldap
>> server is maintained/off/not available...
>>
>>
>
> That is why usually an Ldap client implementation shoud propose to setup 2
> Ldap servers definitions, in order to have one as backup.
>
>
> -> i remember a post, somebody saying its sometimes hard to keep syncd
>> with the Ldap Directory Admin - i agree with that ;-)
>>
>>
> I don't understand. What do you mean by this? Can you give an example ?
>
>
> -> this is also the reason for storing the admins password locally -
>> admin users should always be able to access OM, even if there are
>> compilations with the Ldap Directory Server...
>>
>>
> Let's narrow down the password duplication to admins only then.
>
> Since its always the Ldappassword that has to be correct (in case Ldap
>> is configured)
>>
> Not for Admins. for admins Ldap authentication is always bypassed.
> --- in MainService ---
> // AdminUser werden auf jeden Fall lokal authentifiziert
> if(user != null && user.getLevel_id() >=3){
> log.debug("User " + usernameOrEmail + " is admin -> local
> login");
> withLdap = false;
> }
> --- ---
>
>
> , its not really duplicated, but stored as fallback
>> (this is working without stopping OM Server).
>>
>>
> Well, yes it is duplicated then ;-)
> This method has another pb. It supposes that all authentication systems
> supported by OM in the future will let OM know the user password which is
> not always the case.
>
> Imagine that someone wants to implement an authentication module to support
> the Central Authentication Service (CAS). This SSO system works like this:
> * OM gets a request, and is setup to use CAS, so that it checks if a
> service ticket (either a cookie or GET param) is set
> * OM sees no ticket and redirects the client to the CAS server which
> performs authentication, generate a ticket and redirect the client to OM
> with teh valid ticket set in URL or cookie
> * OM sees the new request with a ticket, it checks the ticket by asking the
> CAS server if it is valid, and then accept the client.
> ==> In this protocol, OM never sees the user password.
>
> It would be a pity to prevent future developpements of any kind of
> authentication systems, just because the first design was supposing a valid
> password is known by OM.
> But this is only my opinion.
>
>
> The userdata should be updated on every successful login , so the db
>> passwd should also always be in sync with the Ldap server. (The only
>> scenario it would fail would be, if LDAP password changes and ldap
>> server is off/not configured in OM, so the local password wouldn't
>> match the current DB password - but coding the fallback for the
>> fallback is not my flavour ;-))
>>
>>
> This will occur as soon as a Ldap user having admin privileges changes his
> LDAP password. I'm sure of this.
>
>
> i dont think i understand the random passowrd bypass via config -how
>> would a OM user authenticate, if Ldap server is off?
>>
>>
> Ldap server should never be off. at least a backup should be online.
> Imigine that a user gets banned from an organization, and the Ldap admin
> delete his account on the Ldap server.
> This user would only have to run a DOS attack on the Ldap server to keep
> his access on the OM system!
>
> So my proposal of a random password was to prevent anyone from login in
> with a user imported from Ldap even if the Ldap server is offline.
> But I see now that we have 2 differents point of view on the matter.
>
> I think then that this behaviour should be switchable in config: having a
> parameter that decides weither or not OM falls back to internal DB auth if
> Ldap is offline.
>
>
> What do you think ?
> Thibault
>
>
>
>> see ya
>>
>> Smoeker
>>
>> On 15 Apr., 13:51, t.lem...@gmail.com wrote:
>>
>>
>>> Hi,
>>>
>>> While reviewing the ldap authentication module, I found out that once
>>> authenticated, OM records and updates the user's password in its
>>> internal DB.
>>> Why is that ?
>>>
>>> In LdapLoginManagement.java: in method doLdapLogin
>>> // Update password (could have changed in LDAP)
>>> u.setPassword(passwd);
>>>
>>> Since all authentications are done on the LDAP server, I think it is a
>>> bad idea to duplicate the password in OM internal DB.
>>>
>>> Is there another good reason to do this ?
>>>
>>> The only reason I see so far is that in MainService, the loginUser
>>> method fails back to non LDAP authentication if the user has admin
>>> privileges. This also means that even if the user changes his password
>>> in LDAP, his old password recorded to the OM db must be used...
>>>
>>> I think it would be better:
>>> * to set a random password value in the OM's Users tables for the Ldap
>>> users
>>> * set a new parameter in om_ldap that will list admin users for which
>>> LDAP auth must be bypassed (in order to keep a local admin login even if
>>> LDAP is badly configured or unavailable).
>>>
>>> What do you think ?
>>>
>>> Thibault
>>>
>>>
>>
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenMeetings User" group.
> To post to this group, send email to openmeetings-u...@googlegroups.com.
> To unsubscribe from this group, send email to
> openmeetings-user+unsubscr...@googlegroups.com<openmeetings-user%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/openmeetings-user?hl=en.
>
>
--
Sebastian Wagner
http://www.webbase-design.de
http://openmeetings.googlecode.com
http://www.laszlo-forum.de
seba.wag...@gmail.com
--
You received this message because you are subscribed to the Google Groups
"OpenMeetings User" group.
To post to this group, send email to openmeetings-u...@googlegroups.com.
To unsubscribe from this group, send email to
openmeetings-user+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/openmeetings-user?hl=en.
